Problem and Interview Evidence
Design a shared key-value cache for many application services. A January 2025 Google L5 candidate reported a task-optimized distributed cache prompt, and a separate May 2026 successful L5 candidate reported distributed cache as the system design round. The exact workload may vary, so clarify value sizes, operations, consistency, and whether a source of truth exists.
Routing and Membership
Choose whether clients route directly or through proxies. Explain membership discovery, consistent hashing or an alternative partition map, virtual nodes, and what happens when a client has stale topology. Adding or replacing a node should move a bounded fraction of keys without allowing rebalancing traffic to overwhelm the cluster.
Consistency and Replication
Define what SET followed by GET means, how replicas are selected, and what failover may return. Compare asynchronous replication, quorum operations, and primary ownership against the cache's role. Compare-and-set needs an explicit serialization point; ordinary cache reads may accept bounded staleness if the caller contract allows it.
Memory, Expiration, and Hot Keys
Size memory using entries, value distribution, metadata, replication, and operational headroom. Keep eviction local to a shard unless the requirements justify coordination. Explain active versus lazy expiration, TTL jitter, admission policy, request coalescing, and selective replication when a hot key dominates a shard.
Failure and Operations
Trace node loss, zone loss, retry storms, replacement, and cache warming. Rebalancing and recovery must be throttled against serving traffic. Define tenant quotas, authentication, noisy-neighbor controls, and metrics for latency, hit rate, eviction, memory pressure, replication lag, errors, and membership health.