Arqly
Sign in
#18Build a distributed cache (Memcached / Pelikan style)
stub
One Redis is easy. A hundred Redises serving 10M QPS with sub-millisecond p99 across a fleet is the real test. Build the client-side consistent-hashing distributed cache: hot-key replication, mirroring for fault tolerance, the thundering-herd dogpile, and the cache-coherence gymnastics that come with sharding.

Build a distributed cache (Memcached / Pelikan style). One Redis is easy. A hundred Redises serving 10M QPS with sub-millisecond p99 across a fleet is the real test. Build the client-side consistent-hashing distributed cache: hot-key replication, mirroring for fault tolerance, the thundering-herd dogpile, and the cache-coherence gymnastics that come with sharding.

This problem is a stub. Suggested approaches haven't been authored yet — ask the staff engineer in the right panel for any stage and they'll generate one tuned to your draft.
Reading: Nishtala et al. — Scaling Memcache at Facebook (NSDI 2013) · Memcached protocol + Twitter Twemcache / Pelikan engineering blog · Twitter — Twemproxy (nutcracker) README and design · Facebook — mcrouter design doc · Karger et al. — Consistent Hashing and Random Trees (STOC 1997) · Cliff Click — A Lock-Free Hash Table (the per-server side)
client-side sharding via consistent hashing + virtual nodes
server-side discovery and ring updates without coordination
hot-key replication and request coalescing
twemproxy / mcrouter as the client-side proxy pattern
negative caching (cache the miss too)
thundering herd / dogpile and probabilistic early expiration
stale-while-revalidate at the cache layer
TTL drift across replicas and the 'who decides expiry' question
consistent-hash vs rendezvous (HRW) hashing — failure overlap
cross-cache invalidation: bus-based vs poll-based vs versioned-keys
No scenes authored for this problem yet.