We use cookies for site analytics. Accept to help us understand how the site is used. See our Privacy Policy for details.
Consistent hashing, eviction, replication, and what really happens when a single hot key takes down the cluster.
Design a distributed in-memory cache: a cluster of nodes that stores key-value pairs with sub-millisecond access latency, sharded across the fleet, with eviction, replication, and graceful failure handling. Clients call get(key) / set(key, value, ttl) / del(key); the system handles the routing, sharding, eviction, and failures invisibly.
This question is dense with specific algorithmic choices (consistent hashing, eviction, quorums) and is a favorite for distributed-systems-heavy roles. Strong candidates name the algorithms, explain the trade-offs, and discuss failure modes explicitly.
Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.
Capacity estimation · architecture with all 5 components explained · 6 deep dives · trade-off analysis · 8 common follow-up questions
Get full access to gitGood.dev with a subscription.
Try everything free for 10 days. Cancel anytime.
10-day trial, then $5/mo - or $40/yr ($3.33/mo, save 33%). Cancel anytime.
The canonical bounded system design problem. Read-heavy, hot-key prone, and a great vehicle for hashing, caching, and capacity estimation.
The classic write-vs-read amplification trade-off. Push, pull, or hybrid fanout - and how to handle the celebrity user with 100M followers.
Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.
Start an AI mock interview →