Technology · In-memory store
Redis
An in-memory data structure server used as a cache, rate limiter, leaderboard, lock service, queue and pub/sub hub. What it's good at, how it scales, and where it bites.
10 min read
Redis keeps data in memory and serves simple operations in well under a millisecond. It's the most common answer when an interviewer asks "where does this fast, shared state live?" Knowing its data structures and its limits lets you use it for far more than caching.
When to reach for it
- Caching database results, rendered pages or sessions, with a TTL on every key.
- Counters and rate limits:
INCRwithEXPIRE, or a token bucket in a Lua script. - Leaderboards: sorted sets give rank and top-N in logarithmic time.
- Short-lived coordination: locks with expiry, deduplication keys, idempotency records.
- Lightweight messaging: pub/sub for fan-out, streams for a small durable log.
Data structures
String
- GET/SET, INCR, SETNX, TTL
- One value per key
Pick it when: Cached blobs, counters, simple locks.
Hash
- Field-level reads and writes
- TTL applies to the whole key
Pick it when: An object's fields, such as a session or user profile.
Sorted set
- Ordered by score
- Rank and range queries in O(log n)
- Memory per member
Pick it when: Leaderboards, time-ordered feeds, sliding-window logs.
Set / List
- Membership, push and pop
- Large ones are slow to scan
Pick it when: Unique visitors, simple queues.
Stream
- Append-only log with consumer groups
- Bounded by memory
Pick it when: Small event logs and job queues when Kafka is overkill.
Probabilistic types (HyperLogLog for unique counts in 12 KB, Bloom filters as a module) and geospatial indexes (GEOADD, GEOSEARCH) cover more interview problems with one tool.
How it works
- Commands execute on a single main thread, one at a time. That's why individual commands are atomic and why one slow command stalls everything.
- Data lives in RAM. Persistence is optional: RDB snapshots periodically, AOF logs every write and can fsync every second.
- Replication is asynchronous from a primary to replicas. Sentinel or a managed service promotes a replica on failure.
- Redis Cluster splits the key space into 16,384 hash slots spread across primaries. Clients route each key to the node owning its slot.
- Latency inside a data centermostly network
- ~0.2–1 ms
- Simple ops per nodemore with pipelining
- 100,000+ per second
- Memory per nodeplan for 2× during snapshots
- tens of GB practical
- Max value sizekeep values small in practice
- 512 MB
Scaling it
- Reads: add replicas, accepting slightly stale reads.
- Writes and memory: shard with Redis Cluster. Multi-key operations only work when all keys share a slot; force that with hash tags such as
{user42}:cartand{user42}:profile. - Hot keys: one key lives on one node, however big the cluster. Replicate it under several key names, or cache it in the application for a second or two.
Where it bites
- Slow commands block everyone.
KEYS *, hugeSMEMBERSor deleting a million-element key freeze the server. UseSCANandUNLINK. - Eviction surprises. When memory fills, the eviction policy (such as
allkeys-lru) silently drops keys. Fine for a cache, wrong for a queue. - Locks need care.
SET key token NX PX 30000is a lease, not a correctness guarantee. Pair it with fencing tokens when a stale holder could corrupt data.
Try it
Real-time Leaderboard HLD
Build a real-time leaderboard on sorted sets.
Learn the ideas
Practice it
Distributed Cache HLDDesign partitioning, bounded staleness and stampede control for a shared cache.Real-time Leaderboard HLDMaintain ordered scores with deduplicated updates, seasons and deterministic ties.Distributed API Rate Limiter HLDCap each client's requests across a fleet of servers without slowing every call.Authentication Session Service HLDManage device sessions, refresh-token rotation and bounded revocation delays.
Related
Relational databasePostgreSQLThe default relational database. Transactions and MVCC, indexes worth knowing, how far one node goes, and the ways to scale it.Coordination serviceZooKeeper and etcdSmall, strongly consistent stores for coordination. What they guarantee, leases and watches, leader election, service discovery and configuration, and what not to put in them.Edge layerAPI GatewaysThe single front door for a service fleet. Routing, authentication, rate limiting, TLS termination, request shaping, and aggregation. How gateways differ from load balancers and service meshes, and how to keep them from becoming a single point of failure.ScalingScaling readsMost systems read far more than they write. The ladder of fixes from indexes to caches, replicas and CDNs, in the order to apply them, and what each costs in freshness.ConsistencyDealing with contentionMany requests competing for the same thing, such as the last seat, one inventory count or a shared counter. Locks, optimistic concurrency, atomic operations, reservations and queues, and when to use each.CommunicationReal-time updatesGetting changes to users within moments. Choosing between polling, SSE and WebSockets, routing events to the right connection server, and handling reconnects and offline users.GeospatialProximity SearchEfficient 2D spatial indexing for geospatial radius and nearest-neighbor queries. Geohashes, hierarchical quadtrees, Google S2 and Uber H3 hexagonal cells, PostGIS R-trees, Redis GEO, moving driver location updates, and nearby places retrieval.