Wie behandelst du einen Hot Key oder eine Hot Row unter starker Contention?

Question

IT Interview Practice · Accepted Answer

**Höre auf, allen Traffic auf einen Key zu leiten: splitte den Hot Key in N Sub-Keys (Sharded Counters), fasse doppelte Reads zusammen, bediene aus einem lokalen Cache und batche Writes, sodass eine Row nicht bei jedem Request aktualisiert wird.** Ein einzelner "Likes"-Zähler auf einem viralen Post kann 50k Writes/Sek. bekommen - eine Row wird zum Serialisierungsengpass, weil jede Transaktion um denselben Lock kämpft.

## Fan-out statt einer umkämpften 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)
```

## Techniken

- **Sharded Counter / Key Splitting.** Schreibe in `likes:123:{0..N}`, zufällig gewählt; der wahre Zähler ist die `SUM`. Das macht aus einer Hot Row N kühlere Rows und senkt die Lock-Contention um ~N. Reads zahlen einen kleinen Fan-in-Aufwand.
- **Request Coalescing (Single-Flight).** Wollen 10k Requests denselben Key gleichzeitig, lass **einen** die DB treffen und den Rest auf dieses In-flight-Ergebnis warten. Verhindert, dass ein Cache-Miss-Stampede die Row zerdrückt.
- **Lokaler (In-Process-)Cache.** Cache den heißen Wert in jedem App-Node für eine kurze TTL (z. B. 1s). Für einen read-heißen Key kollabiert das Tausende Reads/Sek. in einen Refresh - unter Inkaufnahme leichter Staleness.
- **Write-Batching.** Puffere Inkremente im Speicher und flushe `+= 500` einmal pro Sekunde statt 500 einzelner Updates. Ein Row-Update pro Sekunde statt 500 beseitigt die Contention vollständig.

## Interview-Perspektive

Der Interviewer möchte sehen, dass du diagnostizierst, **wo die Contention liegt**, und den Fix an read-hot vs. write-hot anpasst. Read-hot → Cache + Coalescing; write-hot → Sharded Counters + Batching. Eine gute Antwort listet Techniken auf; eine hervorragende Antwort merkt an, dass Sharding **Read-Kosten gegen Write-Skalierbarkeit** tauscht und dass Batching/Caching **Frische gegen Throughput** tauschen.

**Trade-offs & Fallen:** Sharded Counters machen exakte Echtzeit-Summen schwerer (du summierst Shards) und verkomplizieren "Dekrement unter null"-Logik. Lokale Caches driften über Nodes - okay für einen Like-Zähler, falsch für einen Kontostand. Batching riskiert gepufferte Writes zu verlieren, wenn ein Node vor dem Flush crasht, es passt also zu idempotenten/näherungsweisen Zählern, nicht zu Geld. Wähle die Mitigation, die die Consistency-Anforderungen der Daten erlauben.

Fan-out statt einer umkämpften Row

Techniken

Interview-Perspektive

Ähnliche Fragen