Comment gérez-vous 5M de votes en 10 minutes à l'échelle ?

Question

IT Interview Practice · Accepted Answer

N'écrivez pas chaque vote directement dans une ligne de base de données — **bufferisez les écritures, shardez les compteurs, et acceptez un décompte éventuel (eventual tally)**. 5M de votes en 10 minutes, c'est ~8 300 votes/sec en moyenne, avec des pics bien plus élevés (un moment TV en direct peut multiplier cela par 10). L'astuce est de transformer une mise à jour chaude sur une seule ligne en de nombreux incréments indépendants et parallèles.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## Pourquoi bufferiser les écritures

Une queue comme **Kafka** découple l'ingestion du décompte. L'écriture du client est un append bon marché ; si les consumers prennent du retard pendant un pic, les événements attendent dans le log au lieu de submerger la DB. Kafka offre aussi le **replay** — si un consumer crashe, vous retraitez depuis le dernier offset commité sans perdre de votes.

## Les compteurs shardés éliminent le hotspot

Si chaque vote pour « Option A » fait `UPDATE counter SET n=n+1 WHERE id='A'`, cette seule ligne devient un goulot de contention de verrous — des milliers de transactions se sérialisent sur une ligne. À la place, découpez chaque option en **N lignes de shard** (`A:0 … A:63`). Chaque incrément touche un shard aléatoire, donc les écritures se répartissent sur N lignes et s'exécutent en parallèle. Le total affiché est `SUM(shards)`, calculé chaque seconde ou deux par un agrégateur. Dans Redis ce ne sont que N clés `INCR` ; dans DynamoDB, N partition keys.

## Dedup un seul vote

Imposez « un vote par utilisateur » avec une clé d'idempotence : `SADD voted:{pollId} {userId}` (ou un put conditionnel). Si l'utilisateur existe déjà, abandonnez l'événement avant d'incrémenter. Faites cela dans le consumer, pas dans le client — les clients mentent et réessaient.

## Perspective d'entretien

L'examinateur cherche à savoir si vous reconnaissez le **problème de la clé chaude unique (single-hot-key)** et recourez au buffering + sharding plutôt qu'à « ajouter plus de réplicas DB » (les réplicas scalent les lectures, pas cette écriture). Bien : « utiliser une queue et un cache ». Excellent : vous nommez le **compromis d'eventual consistency** — le nombre live est en retard d'une seconde sur la réalité — et argumentez que c'est acceptable pour un décompte de votes mais *pas* pour le résultat final certifié, que vous recalculez de manière autoritaire après la clôture du scrutin.

**Piège courant :** utiliser une transaction de base de données par vote pour la « précision ». À cette échelle, c'est justement ce qui fond.

## Compromis et pannes

- **Décompte éventuel :** les sommes de shards sont en retard ; acceptable pour un compteur live, réconciliez à la clôture.
- **Livraison at-least-once :** Kafka peut redélivrer — la dedup rend les incréments idempotents, sinon vous comptez deux fois.
- **Skew de shard chaud :** trop peu de shards et vous avez encore de la contention ; trop et sommer devient coûteux. 32 à 128 shards est typique.
- **Équité/fraude :** rate-limitez par IP/appareil ; le SET un-seul-vote est votre frontière d'intégrité. Le perdre signifie du bourrage d'urnes, pas un crash — sans doute pire.

Pourquoi bufferiser les écritures

Les compteurs shardés éliminent le hotspot

Dedup un seul vote

Perspective d'entretien

Compromis et pannes

Questions connexes