Comment gérer une clé chaude ou une ligne chaude sous forte contention ?

Question

IT Interview Practice · Accepted Answer

**Cessez de canaliser tout le trafic vers une seule clé : découpez la clé chaude en N sous-clés (sharded counters), coalescez les lectures dupliquées, servez depuis un cache local, et batchez les écritures pour qu'une ligne ne soit pas mise à jour à chaque requête.** Un seul compteur de « likes » sur un post viral peut prendre 50k écritures/sec — une ligne devient un goulot de sérialisation à mesure que chaque transaction se dispute le même verrou.

## Fan-out au lieu d'une seule ligne en contention

```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 / découpage de clé.** Écrivez dans `likes:123:{0..N}` choisi aléatoirement ; le vrai compteur est la `SUM`. Cela transforme une ligne chaude en N lignes plus froides, réduisant la contention de verrous d'environ N. Les lectures paient un petit coût de fan-in.
- **Request coalescing (single-flight).** Si 10k requêtes veulent la même clé en même temps, laissez-en **une** frapper la DB et faites attendre les autres sur ce résultat en cours. Empêche un stampede de cache-miss d'écraser la ligne.
- **Cache local (in-process).** Cachez la valeur chaude dans chaque nœud applicatif pour un court TTL (par ex. 1s). Pour une clé read-hot, cela effondre des milliers de lectures/sec en un seul refresh — en acceptant une légère péremption.
- **Write batching.** Bufferisez les incréments en mémoire et flushez `+= 500` une fois par seconde au lieu de 500 mises à jour unitaires. Une mise à jour de ligne par seconde au lieu de 500 élimine entièrement la contention.

## Perspective d'entretien

L'examinateur veut vous voir diagnostiquer **où se trouve la contention** et adapter le correctif au read-hot vs write-hot. Read-hot → cache + coalescing ; write-hot → sharded counters + batching. Une bonne réponse liste les techniques ; une excellente note que le sharding échange le **coût de lecture contre la scalabilité d'écriture**, et que batching/caching échangent la **fraîcheur contre le throughput**.

**Compromis & pièges :** les sharded counters rendent les totaux exacts en temps réel plus difficiles (vous sommez les shards) et compliquent la logique « décrémenter en dessous de zéro ». Les caches locaux dérivent entre nœuds — acceptable pour un compteur de likes, faux pour un solde bancaire. Le batching risque de perdre les écritures bufferisées si un nœud crashe avant le flush, donc il convient aux compteurs idempotents/approximatifs, pas à l'argent. Choisissez l'atténuation que les besoins de cohérence des données permettent.

Fan-out au lieu d'une seule ligne en contention

Techniques

Perspective d'entretien

Questions connexes