Redis Study Guide

Covers: Data Types, Caching Patterns & Invalidation, Cache Stampede, Sorted Sets, Pub/Sub, Geo, Distributed Locks, Persistence, Replication & Scaling

Redis is a single-threaded in-memory data store. Commands execute one at a time, in order — no lock contention, and operations like INCR are atomic by default. This is what makes Redis safe for distributed coordination without explicit synchronization. Redis 6+ added I/O threads for network reads/writes, but command execution remains sequential. The bottleneck is almost never the thread — it's network round trips, which pipelining solves.

1. Data Types — The Swiss Army Knife

2. Caching Patterns

Pick One Per Use Case

Eviction Policies

• LRU (Least Recently Used) — evict the item not accessed for the longest time. Default for most use cases.
• LFU (Least Frequently Used) — evict the item accessed least often. Better for skewed access patterns.
• TTL (Time To Live) — expire entries after a fixed time. Good for data that goes stale.

TTL Tiering — Driven by Your NFRs

Don't pick arbitrary TTLs — derive them from consistency requirements:

When NOT to Cache

• Real-time collaborative systems — Google Docs, multiplayer games. Every change must be immediately visible. Caching actively hurts.
• Strongly consistent financial data — account balances, inventory when overselling is catastrophic.
• Write-heavy systems — if read/write ratio is ~1:1 or 2:1, hit rates are too low to justify the complexity.
• User-specific private data — private messages, personal preferences. Only one user ever requests them — no cache hit rate benefit.

3. Cache Invalidation

Most production systems combine approaches — short TTL as a safety net plus active invalidation for critical data.

4. Cache Stampede (Thundering Herd on Expiry)

When a popular cache entry expires, all concurrent requests see a cache miss simultaneously and race to rebuild it from the DB. At 100K reads/sec, that's 100K identical DB queries in the same instant — the DB collapses under a self-inflicted load spike.

Three mitigations:

1. Probabilistic early refresh — as the entry ages, each request has a small increasing probability of triggering a background refresh. At 50 min into a 60-min TTL: 1% chance. At 59 min: 20%. By expiry, the entry is already refreshed. No stampede ever occurs. Cleanest solution for most cases.

2. Background refresh process — a dedicated job refreshes critical entries before TTL expires. Guarantees the entry never goes cold. Cost: wasted refreshes for unrequested keys.

3. Request coalescing — when multiple requests see the same miss, only one fetches from DB; the rest wait for that result.

CopyCache miss for "celebrity:123"
→ Server 1: acquires in-flight lock, fetches from DB, populates cache
→ Server 2: sees in-flight lock, waits for Server 1's result
→ DB hit exactly once per app server — not once per user

Hot key fanout — for extreme loads: store copies under multiple keys (feed:taylor-swift:1 … feed:taylor-swift:10). Readers randomly pick one. Spreads 500K req/sec across 10 keys. Tradeoff: memory × N copies, invalidation must clear all.

5. Sorted Sets — Leaderboards and Rankings

A set where every member has a numeric score. All range queries by score are O(log n).

Commands:

• ZADD leaderboard 9500 "user:42" — add or update member with score
• ZREVRANGE leaderboard 0 9 WITHSCORES — top 10 by score, descending
• ZRANK leaderboard "user:42" — rank of a member (0-indexed from lowest)
• ZREVRANK leaderboard "user:42" — rank from highest (0 = top)
• ZRANGEBYSCORE leaderboard 8000 +inf — all members with score ≥ 8000

Limits:

• Max members per key: ~4.3 billion
• Memory per member: ~50–100 bytes overhead + key + value size
• At 10M members: ~500MB–1GB RAM — comfortable on a typical instance
• All operations O(log n)

Other uses beyond leaderboards:

• Priority queues — score is priority level; pop with ZPOPMIN
• Expiring job queues — score is execute-at timestamp; worker polls with ZRANGEBYSCORE jobs 0 <now>
• Rate limiting — score is request timestamp; count members in sliding window with ZCOUNT

Real example: Gaming leaderboard — score is points, member is user ID. Top 10 is a single ZREVRANGE call. Rank lookup for any user is ZREVRANK — O(log n) regardless of how many players.

6. Pub/Sub — Fan-out Notifications

Publisher sends to a channel. All current subscribers receive it instantly. Fire-and-forget — no persistence, no queue.

CopyPUBLISH  notifications:user:42  '{"type":"seat_reserved","seat":"A12"}'
SUBSCRIBE notifications:user:42   → receives the message instantly

Limitation: Messages are lost if no subscriber is listening at that moment. A subscriber joining late gets nothing from before they subscribed. Redis crash = all in-flight messages lost.

Limits:

• Throughput: millions of messages/sec — no disk I/O
• Channels: unlimited (memory bound — each active channel with subscribers uses RAM)
• Not suitable for > 10K active channels with high-volume subscribers without careful memory planning

Pub/Sub vs Kafka

Real example: Chat service — WebSocket servers subscribe to room:{roomId}. When a user sends a message, publish once → all servers with subscribers receive it and push to their connected clients. No need to know which server holds which connection.

7. Geo — Proximity Queries

Redis Geo is a sorted set where the score is a 52-bit geohash. Enables radius and bounding box queries in O(n + log m). Best solution for high-frequency location updates at scale.

Commands:

• GEOADD drivers -74.006 40.713 "driver:42" — add or update location (overwrites previous — always have latest)
• GEOSEARCH drivers FROMLONLAT -73.99 40.72 BYRADIUS 5 km ASC COUNT 20 — nearest 20 within 5km
• GEOSEARCH drivers FROMLONLAT -73.99 40.72 BYBOX 10 10 km ASC — within bounding box
• GEODIST drivers driver:42 driver:99 km — distance between two members
• GEOSEARCH drivers FROMMEMBER driver:42 BYRADIUS 5 km ASC — search from an existing member's position

GEOSEARCH (Redis 6.2+) replaces the older deprecated GEORADIUS and GEORADIUSBYMEMBER.

Precision levels:

Full ride-sharing pattern:

CopyDriver update every 5 seconds:
  → GEOADD drivers <lng> <lat> "driver:42"
  → ZADD driver_timestamps <unix_ts> "driver:42"   ← companion set to track last-seen

Rider requests match:
  → GEOSEARCH drivers FROMLONLAT <lng> <lat> BYRADIUS 5 km ASC COUNT 20

Stale driver cleanup (runs every 30s):
  → ZRANGEBYSCORE driver_timestamps 0 <now - 30s>  ← drivers not updated in 30s
  → ZREM driver_timestamps <stale_ids>
  → ZREM drivers <stale_ids>

The companion driver_timestamps sorted set (score = last-seen timestamp) is essential — without it, offline drivers stay in the geo set forever and appear available to riders.

Durability note: Driver locations are ephemeral — every driver re-reports within 5 seconds. A Redis crash means ~5s of stale data before the set rebuilds. State this tradeoff explicitly in an interview. Mitigate with RDB snapshots or Redis Sentinel if needed.

Write optimization patterns for high-frequency updates:

Limits:

• ~4.3 billion members per key (same as sorted sets — it's built on them)
• Coordinate precision: ~0.6mm at equator
• Radius query: O(n + log m) — fast up to millions of members

8. Distributed Locks

Prevents two workers from processing the same job simultaneously. In-memory locks only exist within one instance — SETNX moves the lock into a shared, atomic, external store.

Why not a DB transaction lock? DB transaction locks hold for the life of a transaction — designed for millisecond durations. Distributed locks hold for longer (e.g. seat reserved for 10 minutes while user pays). Using a DB transaction for that would block the row and kill throughput.

Option 1 — Redis SETNX (simple, fast)

CopySET lock:job_123 worker_A NX PX 30000

NX = only set if not exists. PX 30000 = expire in 30 seconds (auto-release if worker crashes).

• Fast (~1ms)
• Single Redis node = single point of failure
• Clock drift can theoretically cause two nodes to hold the lock simultaneously

Option 2 — Redlock (multiple Redis nodes)

Acquire lock on a majority (3 of 5) Redis nodes within a time window. More robust than single-node but controversial — a process can pause (JVM GC) after acquiring the lock, TTL expires across all nodes, and another process acquires it. Both now believe they hold it.

The Redlock debate: Martin Kleppmann argued it's unsafe due to process pauses. Antirez (Redis creator) rebutted that extreme GC pauses are unlikely in practice. Never fully resolved. Practical takeaway: Redlock is fine when occasional double execution is survivable.

Option 3 — etcd (strongest guarantee)

Uses Raft — lock acquisition is linearizable. No clock drift issues. Slower (~5–10ms). Use when correctness is mandatory.

Fencing Tokens — the Correct Solution for Strong Safety

Every etcd write returns a monotonically increasing revision number. Pass this as a token to the protected resource. The resource rejects any request with a lower token than the last seen.

CopyProcess A acquires lock → gets token 42
Process A pauses (GC)
Lock expires → Process B acquires → token 43 → writes with token 43
Process A wakes up → tries to write with token 42 → resource rejects (42 < 43) ✓

Redis has no equivalent. If you need this level of correctness, use etcd.

When to Use Each

Real examples: Seat reservation (lock seat for 10 min while user pays), ride-share driver assignment (prevent matching one driver to two riders), distributed cron jobs (run on exactly one server).

9. Persistence

AOF + RDB can be combined — Redis uses both for recovery, whichever is more complete.

10. Replication and Scaling

Redis Sentinel — High Availability

Monitors a primary + replica setup. Auto-promotes a replica when the primary fails (~seconds). All data lives on one primary (replicated to replicas). Read traffic distributes across replicas.

Use when: dataset fits on one node, you need HA without sharding complexity.

Redis Cluster — Horizontal Scale

Shards data across multiple primaries using 16,384 hash slots. Each shard has its own primary + replicas with built-in per-shard failover.

Use when: dataset too large for one node OR write throughput exceeds single-node capacity.

Sentinel vs Cluster

Capacity Reference