How do you handle a hot key or hot row under heavy contention?

Question

IT Interview Practice · Accepted Answer

**Stop funnelling all traffic to one key: split the hot key into N sub-keys (sharded counters), coalesce duplicate reads, serve from a local cache, and batch writes so one row isn't updated on every request.** A single "likes" counter on a viral post can take 50k writes/sec — one row becomes a serialization bottleneck as every transaction fights for the same lock.

## Fan-out instead of one contended row

```text
                 50k inc/sec on post:123
                          │
             hash(request) % N   (split the key)
        ┌────────┬────────┬────────┬────────┐
        ▼        ▼        ▼        ▼        ▼
   likes:123:0  :123:1  :123:2  :123:3  :123:4   ← sharded counters
        └────────┴───┬────┴────────┴────────┘
                     ▼
             SUM on read = total     (read fans in)
```

## Techniques

- **Sharded counter / key splitting.** Write to `likes:123:{0..N}` chosen at random; the true count is the `SUM`. This turns one hot row into N cooler rows, cutting lock contention by ~N. Reads pay a small fan-in cost.
- **Request coalescing (single-flight).** If 10k requests want the same key at once, let **one** hit the DB and have the rest wait on that in-flight result. Prevents a cache-miss stampede from crushing the row.
- **Local (in-process) cache.** Cache the hot value in each app node for a short TTL (e.g. 1s). For a read-hot key, that collapses thousands of reads/sec into one refresh — accepting slight staleness.
- **Write batching.** Buffer increments in memory and flush `+= 500` once per second instead of 500 single updates. One row update per second instead of 500 removes the contention entirely.

## Interview perspective

The interviewer wants to see you diagnose **where the contention is** and match the fix to read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → sharded counters + batching. Good answer lists techniques; great answer notes that sharding trades **read cost for write scalability**, and that batching/caching trade **freshness for throughput**.

**Trade-offs & traps:** sharded counters make exact real-time totals harder (you sum shards) and complicate "decrement below zero" logic. Local caches drift across nodes — fine for a like count, wrong for a bank balance. Batching risks losing buffered writes if a node crashes before flush, so it suits idempotent/approximate counters, not money. Pick the mitigation the data's consistency needs allow.

Fan-out instead of one contended row

Techniques

Interview perspective

Related questions