Comment construire un compteur de vues/likes en temps réel pour des posts viraux ?

Question

IT Interview Practice · Accepted Answer

Ne faites jamais `UPDATE posts SET views = views + 1` par événement sur un post chaud — cette seule ligne devient un goulot de verrouillage. **Incrémentez dans Redis, flushez par batch vers la DB** toutes les quelques secondes, et lisez le compteur depuis Redis. La DB stocke les totaux durables, pas le trafic live.

## Architecture

```text
Client tap ─▶ API ─▶ Redis INCR views:{post}   (live, source of truth for reads)
                          │            └── dedup: SADD seen:{post} {user/ip}
                          ▼
                 every ~5s / N ops
              Flusher ─▶ UPDATE posts SET views = views + delta   (durable)
                          ▲
                 read path: GET Redis (fallback DB on miss)
```

## Composants et flux

- **Redis INCR** absorbe la tempête d'écritures. Un seul `INCR views:{post}` est atomique et gère 100k+ ops/s sur une clé — des ordres de grandeur au-delà d'une ligne Postgres. Ce compteur est la source de vérité pour les *lectures*, donc les spectateurs voient le nombre bouger instantanément.
- **Dedup pour les likes/vues uniques** : un compteur brut compte deux fois les rafraîchissements. Utilisez `SADD seen:{post} {userId}` et n'`INCR` que lorsque l'ajout est nouveau ; pour des uniques approximatifs à bas coût à très grande échelle utilisez **HyperLogLog** (`PFADD`/`PFCOUNT`) — quelques Ko estiment des millions d'uniques à ~2% d'erreur près.
- **Flusher par batch** draine périodiquement le delta vers la DB : `UPDATE posts SET views = views + delta`. Flusher toutes les 5s ou tous les N incréments transforme un million d'écritures en une poignée — la DB détient le total durable pour les posts froids et l'analytique.
- **Chemin de lecture** sert depuis Redis ; sur un cache miss il lit le total en DB et re-warm Redis. Les likes nécessitent un état par utilisateur (est-ce que *moi* je l'ai liké), donc stockez le set, pas seulement un nombre.

## Perspective d'entretien

Les examinateurs testent si vous acceptez l'**eventual consistency pour les compteurs**. « Bien » c'est « cacher le compteur » ; « excellent » c'est bufferiser les *écritures* — reconnaître que le goulot est la contention d'écriture sur une ligne chaude, pas la charge de lecture. Ils sondent le compromis : un compteur approximatif est-il acceptable ? Pour les compteurs de vues, oui — personne ne remarque 1 203 428 vs 1 203 450. Le piège est de s'inquiéter des compteurs exacts et de recourir à une transaction, réintroduisant le verrou que vous évitiez.

## Compromis et pannes

- **Exactitude vs throughput** : les compteurs exacts nécessitent des sets de dedup (gourmands en mémoire) ; le HyperLogLog approximatif est minuscule et rapide. Choisissez par fonctionnalité — les likes sont exacts, les compteurs de vues peuvent être approximatifs.
- **Durabilité** : Redis est en mémoire. S'il meurt avant un flush, vous perdez le delta non flushé. Activez l'AOF et gardez des fenêtres de flush courtes (secondes) pour borner la perte ; le total DB plus un petit écart est acceptable pour un compteur de vues.
- **Clé chaude** : un post viral concentre tout le trafic sur une seule clé Redis. Shardez-la en `views:{post}:{0..9}` et sommez à la lecture, ou routez les clés chaudes vers un nœud dédié pour qu'un post ne puisse pas saturer le shard.

Architecture

Composants et flux

Perspective d'entretien

Compromis et pannes

Questions connexes