Redis Basics
In-memory data store. Keys to strings, hashes, lists, sets, sorted sets. Durable to disk. Sub-ms latency. Swiss army knife for caching, queues, counters, locks.
1 credit
Data types (what you'll use)
7 itemsString
`SET key value` / `GET key` / `INCR counter` — atomic counterHash
`HSET user:1 name Alice age 30` — tiny record, cheaper than JSON+SETList
`LPUSH queue job` / `BRPOP queue 0` — blocking pop = simple queueSet
`SADD tags ssd ram` / `SINTER` — unique members, set mathSorted set (zset)
`ZADD lb 100 alice` / `ZRANGE lb 0 9 WITHSCORES` — leaderboards, time-ordered feedsStream
`XADD events * k v` / `XREAD` — append-only log, Kafka-litePub/Sub
`PUBLISH ch msg` / `SUBSCRIBE ch` — fanout, no persistenceCaching pattern
text
GET cache:user:42
MISS → SELECT * FROM users WHERE id = 42
SET cache:user:42 <json> EX 300 (5-min TTL)
HIT → parse + returnAlways set TTL on cache keys. "Cache forever" keys are how stale data ships.
Operational
5 itemsCheck memory
INFO memoryBiggest keys
redis-cli --bigkeysLive commands
redis-cli MONITOR (don't do this in prod — blocks)TTL on key
TTL key (seconds remaining; -1 no expiry; -2 gone)Find keys matching
SCAN 0 MATCH user:* COUNT 1000 (NEVER use KEYS — blocks)Pitfalls
- Single-threaded — one slow command (big SORT, KEYS *) blocks everything.
- Not a durable database. Use for cache / queue / ephemeral state; keep source of truth in Postgres.
- Unbounded keys = OOM — set TTL or use `maxmemory-policy allkeys-lru`.
- Replication + sentinel for HA — single-node Redis in prod = guaranteed outage eventually.