Redis

You don’t need a system install to learn Redis — one container gives you a clean, throwaway server on the default port 6379. redis-cli is the interactive client that ships with Redis; PING is the liveness check that returns PONG when the server is reachable. Everything in this track runs against this one local server.

The string is Redis’s most basic type — a key mapped to a value (text or binary, up to 512 MB). What makes Redis a cache rather than a hashmap is expiry: SET key value EX 60 stores the value and tells Redis to delete it automatically after 60 seconds. TTL key shows the seconds remaining (-1 means no expiry, -2 means the key is already gone). Expiry is what keeps a cache from growing without bound.

Counting page views or API hits with GET then SET key value+1 has a race: two clients read the same number and both write back the same increment, losing a count. INCR does the read, add, and write as one atomic operation on the server, so concurrent callers never collide. INCRBY adds an arbitrary amount, and INCR even initialises a missing key to 0 first. This single guarantee is the foundation of rate limiting and metrics in Redis.

When you have several fields that belong to one entity — a user’s name, email, and login count — you could make three string keys, but a hash keeps them under one key as a field→value map. HSET user:42 name alice email a@x.io writes two fields; HGETALL user:42 returns them all; HINCRBY atomically bumps a numeric field. One key per object means one expiry, one delete, and far fewer keys to manage.

A sorted set stores unique members each with a floating-point score, kept ordered by score at all times. ZADD game scores member inserts or updates in O(log N); the set is always sorted, so reading the top of the board is cheap. Members with equal scores are ordered lexicographically by member name (which ZREVRANGE then reverses, so a tie can put the later name first). ZREVRANGE key 0 9 WITHSCORES returns the ten highest scorers, highest first; ZRANK / ZREVRANK give a member’s position; ZINCRBY bumps a score atomically. Doing this in a relational store means an ORDER BY ... LIMIT and an index scan on every read — Redis keeps the ranking maintained for you.

A Redis list is an ordered sequence you push to and pop from either end. Treat it as a job queue: producers LPUSH queue payload onto the left, a worker BRPOP queue 0 pops from the right (FIFO order). BRPOP blocks until an item arrives or a timeout elapses, so the worker isn’t spinning in a busy loop. This is the simplest durable-enough queue you can stand up; for at-least-once delivery and consumer groups, graduate to Redis Streams (XADD / XREADGROUP).

Redis pub/sub decouples senders from receivers: a publisher PUBLISH room:42 "hello" sends to a channel, and every client currently SUBSCRIBEd to room:42 receives it. It’s fire-and-forget — messages are not stored, so a subscriber that isn’t connected when you publish never sees that message. That makes it perfect for real-time fan-out (chat, live presence, “someone joined”) and wrong for anything that needs durability or replay. When you need persistence and consumer groups, reach for Streams instead.

MULTI opens a transaction; the commands you queue after it don’t run until EXEC, and then they run sequentially with no other client interleaving. This is how you keep two related writes consistent — e.g. remove a player from one set and add them to another. Redis transactions are not rollback-on-error like SQL: if a queued command fails at runtime the others still apply. For optimistic concurrency, WATCH a key first — if it changes before EXEC, the transaction aborts and you retry. For genuinely atomic read-decide-write logic, a Lua script (next Step) is usually cleaner.

Some logic needs to read a value, decide, and write back as one indivisible step — a token-bucket rate limiter is the classic case. EVAL runs a Lua script atomically inside Redis: nothing else executes while it runs, so there’s no window for a race. The script below increments a per-window counter, sets the expiry only on the first hit, and returns whether the caller is over the limit. In production, load it once with SCRIPT LOAD and call it by SHA with EVALSHA to avoid re-sending the body.

Redis is in-memory but can persist to disk two ways. RDB takes periodic point-in-time snapshots — compact, fast to restart from, but you can lose everything written since the last snapshot on a crash. AOF logs every write command and replays it on restart; with appendfsync everysec you lose at most ~1 second of writes, at the cost of a larger file and slightly more I/O. You can run both. The honest framing for this curriculum: even with AOF, Redis is a fast complement to your durable store, not the system of record for data you can’t lose. Size your dataset to fit in RAM, and back the source of truth with PostgreSQL or MongoDB.

KEYS pattern walks the entire keyspace in one blocking call — on a large production server it freezes Redis for every other client. SCAN is the safe alternative: it returns a cursor and a small batch of keys per call, so you iterate incrementally without blocking. Pair it with MATCH for a pattern and COUNT as a hint for batch size. For operability, INFO memory shows total usage and the eviction policy, and MEMORY USAGE key reports the bytes a single key costs — essential when you’re deciding what to cache and for how long.