Courses › System Design › Key Technologies

Redis

Caching, distributed locks, leaderboards, rate limiting, pub/sub and streams.

Redis is an in-memory data store that shows up in more system design interviews than any other technology. It's not just a cache: its data structures make it a Swiss Army knife for leaderboards, rate limiting, locks, queues and real-time messaging. Knowing it well lets you solve a surprising number of deep dives in one sentence.

Why it's fast

  • In memory — sub-millisecond operations
  • Single-threaded command execution — no locks, and every command is atomic
  • Simple data structures with known complexity

The trade-off is that the dataset must fit in memory (or be sharded across nodes), and durability is weaker than a disk-first database.

Data structures and what they're for

Common patterns

Cache

The most common use. Cache-aside with a TTL — see Caching.

Distributed lock

SET lock:seat:A12 <request-id> NX PX 10000
# NX = only set if not exists; PX = expire after 10s

NX makes acquisition atomic; the expiry guarantees the lock is released if the holder crashes. Release it only if you still own it (compare the value in a Lua script). For correctness-critical locking, pair it with a fencing token checked by the database — expiry-based locks can't guarantee mutual exclusion through long GC pauses.

Rate limiting

A fixed-window limiter is two commands:

INCR rate:user:42:202610091200
EXPIRE rate:user:42:202610091200 60

For a token bucket or sliding window, run the read-modify-write in a Lua script so it's atomic across concurrent gateways. See Design a Rate Limiter.

Leaderboard

ZINCRBY leaderboard 10 "user:42"
ZREVRANGE leaderboard 0 9 WITHSCORES   # top 10
ZREVRANK leaderboard "user:42"         # a user's rank

All O(log n). This is the canonical answer for "top players" and "trending" lists at moderate scale.

Proximity search

GEOADD drivers -122.33 47.61 driver:7 and GEOSEARCH drivers FROMLONLAT -122.33 47.61 BYRADIUS 2 km — perfect for frequently updated locations, like drivers that move every few seconds.

Pub/Sub and Streams

  • Pub/Sub is fire-and-forget fan-out: great for routing chat messages or real-time updates between servers, but messages are lost if no subscriber is listening.
  • Streams persist messages and support consumer groups with acknowledgements — a lightweight alternative to Kafka for modest volumes.

Scaling and durability

  • Replication — a primary with asynchronous replicas; Sentinel or a managed service handles failover. Because replication is async, a failover can lose the last few writes.
  • Redis Cluster — shards keys across nodes using 16,384 hash slots. Multi-key operations only work when keys live on the same slot (use hash tags like {user:42}:cart).
  • Persistence — RDB snapshots and/or an append-only file (AOF). Even with AOF, treat Redis as a cache or a coordination layer unless you've explicitly reasoned about data loss.

[!INTERVIEW] Watch for hot keys A single key (one celebrity's follower count, one flash-sale item) lives on one node. If it receives too much traffic, shard the value across several keys (count:item:9:{0..15}) and sum on read, or add an in-process cache in front.