Cum gestionezi o cheie fierbinte sau un rând fierbinte sub contenție grea?

Question

IT Interview Practice · Accepted Answer

**Oprește canalizarea întregului trafic către o singură cheie: împarte cheia fierbinte în N sub-chei (contoare sharded), coalescează citirile duplicate, servește dintr-un cache local și fă batch la scrieri, astfel încât un rând să nu fie actualizat la fiecare request.** Un singur contor de "aprecieri" pe o postare virală poate primi 50k scrieri/sec — un rând devine un blocaj de serializare pe măsură ce fiecare tranzacție se luptă pentru același lock.

## Fan-out în loc de un rând contestat

```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)
```

## Tehnici

- **Contor sharded / împărțirea cheii.** Scrie în `likes:123:{0..N}` ales aleator; numărul real este `SUM`-ul. Asta transformă un rând fierbinte în N rânduri mai reci, tăind contenția de lock cu ~N. Citirile plătesc un mic cost de fan-in.
- **Request coalescing (single-flight).** Dacă 10k request-uri vor aceeași cheie deodată, lasă **unul** să lovească DB-ul și fă-i pe ceilalți să aștepte acel rezultat in-flight. Împiedică un stampede de cache-miss să zdrobească rândul.
- **Cache local (in-process).** Pune valoarea fierbinte în cache în fiecare nod de aplicație pentru un TTL scurt (de ex. 1s). Pentru o cheie read-hot, asta colapsează mii de citiri/sec într-un singur refresh — acceptând o ușoară învechire.
- **Batching de scrieri.** Buffer-uiește incrementările în memorie și golește `+= 500` o dată pe secundă în loc de 500 de update-uri individuale. Un update de rând pe secundă în loc de 500 elimină complet contenția.

## Perspectiva de interviu

Intervievatorul vrea să te vadă diagnosticând **unde este contenția** și potrivind fix-ul cu read-hot vs write-hot. Read-hot → cache + coalescing; write-hot → contoare sharded + batching. Un răspuns bun listează tehnicile; unul excelent observă că sharding-ul compensează **costul de citire pentru scalabilitate de scriere** și că batching-ul/caching-ul compensează **prospețimea pentru throughput**.

**Compromisuri și capcane:** contoarele sharded fac totalurile exacte în timp real mai grele (însumezi shard-uri) și complică logica de "decrement sub zero". Cache-urile locale derivează între noduri — în regulă pentru un număr de aprecieri, greșit pentru un sold bancar. Batching-ul riscă pierderea scrierilor buffer-uite dacă un nod cade înainte de flush, deci se potrivește contoarelor idempotente/aproximative, nu banilor. Alege atenuarea pe care o permit nevoile de consistență ale datelor.

Fan-out în loc de un rând contestat

Tehnici

Perspectiva de interviu

Întrebări conexe