Topic 10.9
Distributed Cache
In one line
A cache that scales beyond one machine and is shared by the whole fleet — Redis Cluster or a sharded layer.
Think of it like this
A single fridge shared by every apartment in a building instead of one fridge per flat. Everyone benefits from the same cached food, but the building needs a plan for what happens if the shared fridge breaks.
Key ideas
- 01
One big shared cache vs per-node local caches: shared = one hot set across fleet, best for high churn; local = cheapest, finest per-instance hit.
- 02
Redis Cluster: slots (16384) mapped via consistent hashing, replicas for failover, MOVED redirect for clients.
- 03
Two levels often coexist: L1 local Caffeine + L2 Redis -> the 'two-tier cache' with its invalidation protocol.
- 04
Distributed invalidation is the pain: evict on write via events; TTL jitter for expiry spread; versioned keys.
- 05
Cache should be REPLACEABLE: if it dies, app falls back to DB (cache-aside does this naturally).
- 06
Interview: 'Redis Cluster for the hot working set, local caches for read-mostly static' is the mature layering.
Java / Spring map
- →
Caffeine local + Redis Cluster as L2 via Spring Cache composite; Lettuce client.
Explain without notes
Why is a single Redis instance a single point of failure for a critical path — and what does Cluster Sentinel fix?
Practice
Design the two-tier cache for a product catalog with an explicit invalidation fan-out.
Trade-offs
- ↔
Every cache hop adds operations complexity; a local-only cache saves that at the cost of cross-instance staleness.
Run it in production
You've designed it. Now build, operate, and break the same idea hands-on in the DevOps courses:
Completion checklist
I can layer L1/L2 caches and specify failover + invalidation for the fleet.