Distributed cache
0-day streakReview

Your progress

Level 1

0 XP100 XP to level 2
0day streak
0best streak
0topics started
0cards reviewed
    Review cards

    Progress is stored only in this browser. No account is required.

    Design a distributed cache: the 60-second story

    Design a distributed cache

    To 200 teams it’s one hash table. Underneath sit 300 machines.

    Peak: 10 million operations a second, each well under a millisecond. Any item may vanish at any moment.

    450k/s

    misses reach the databases, at 95% hits

    Without the cache they’d see 9M reads a second, 20 times as many. Slip to 90% hits and misses double.

    Which node holds a key?

    Bad: hash mod N

    From 250 to 251 nodes, 99.6% of keys move and miss.

    Good: 16,384 hash slots

    Each node owns ≈ 65; a new node takes 65, moving ≈ 0.4% of keys.

    The reader’s old price lands after the writer’s delete

    A lease fixes it. The miss returns token L1; the delete voids it; the late ₹999 fill is dropped.

    Four rules keep the cache honest

    1. Commit, then delete the key
    2. Deletes void leases, so stale fills drop
    3. Commit-log deletes reach every zone in ≈ 1 s
    4. Every key’s TTL caps the damage

    The ₹9,999 phone’s key expires at 50,000 reads/s. A 50 ms refill lets in 2,500 identical queries.

    The trick

    Reuse the lease. One per key every few seconds; others briefly wait. One query, fleet-wide.

    2,500/s

    of 1M reads/s reach the cache

    World Cup final, last over: one 2 KB score key, on one node budgeted for 200k. Each sidecar holds it for one second.

    A node dies. Send its traffic to the gutter.

    Rehash, and a neighbour inherits its hot keys, slows and fails too. Instead, 3 idle gutter nodes refill with a 10 s TTL.

    Remember

    Hash slots route each key to one node. Commit, then delete; leases and the commit log keep it honest. A cache failure makes you slower, never down.