Question presented to candidate: "Design a distributed in-memory cache that our services can use instead of one Redis box. It should hold about half a terabyte, take around a million operations per second at peak, and keep working when a node dies. Walk me through how keys are placed, how clients find them, and what happens when we add a node or one fails."
What a strong answer should cover:
- Requirements and a capacity estimate with numbers: data size with overhead, memory headroom per node, number of shards and replicas, operations and bandwidth per node
- Partitioning: hash slots (Redis Cluster uses CRC16 of the key mod 16,384) or a consistent-hash ring, and why
hash mod Nis wrong (most keys move when N changes) - Routing: a smart client with a slot map and redirects (
MOVED/ASK), or a proxy tier; hash tags to keep related keys together for multi-key operations - Replication and failover: a primary plus replicas per shard, asynchronous replication, failure detection and promotion, and the honest consequence that acknowledged writes can be lost
- Per-node behaviour: memory limit, eviction policy (approximated LRU/LFU), TTL expiry
- Hot keys and stampedes: a near (in-process) cache or key replication for hot keys, request coalescing or leases for misses, and the database behind the cache surviving a cold start
Clarifying questions expected:
- Is it a pure cache (data can be rebuilt from a database) or must it be durable?
- What are the value sizes, the read/write ratio and the latency target (p99)?
- Do callers need multi-key operations or transactions across keys?
Code / implementation expected: Optional โ the routing logic (key to slot to node) and the resharding arithmetic are worth sketching; the example implements them.