Concevez un leaderboard en temps réel pour des millions de joueurs

Question

IT Interview Practice · Accepted Answer

**Utilisez un sorted set Redis (ZSET) indexé par score : le rang et le top-N deviennent des opérations natives en O(log N), donc vous ne triez jamais des millions de lignes par requête.** Un ZSET garde les membres ordonnés par score automatiquement ; c'est exactement ce qu'est un leaderboard.

## Architecture

```text
Game svc ──ZADD score──▶ Redis ZSET (sorted by score) ──ZREVRANGE 0 99──▶ Top-100 API
                              │
                              ├─ ZREVRANK user ─▶ "your rank" (around-me: rank±5)
                              └─ AOF/RDB + async ─▶ Postgres (durable source of truth)
```

## Comment ça fonctionne

- **ZADD** upsert le score d'un joueur en O(log N). Redis maintient l'ordre via une **skip list**, donc aucun re-tri n'est nécessaire.
- **Top-N** : `ZREVRANGE board 0 99 WITHSCORES` retourne le top 100 en O(log N + 100).
- **Votre rang** : `ZREVRANK board user` donne la position en base 0 ; l'**around-me** est `ZREVRANGE rank-5 rank+5` — la tranche de joueurs proches de vous.
- **Durabilité** : Redis est en mémoire. Activez l'**AOF** (append-only file) pour le replay, et mirroir­ez les scores de façon asynchrone vers **Postgres** comme véritable système d'enregistrement, pour qu'une perte de Redis soit récupérable.

## Sharding pour des millions d'utilisateurs

Un seul ZSET détient sans problème des dizaines de millions de membres (borné par la mémoire, ~100MB pour 1M d'entrées). Au-delà, ou pour une échelle globale, **shardez par tranche de score** (0–1k, 1k–10k…) pour que chaque shard soit une bande contiguë — un top-N global ne lit que le shard supérieur. Évitez de sharder par hash d'utilisateur : recombiner les rangs à travers des shards aléatoires est coûteux.

## Perspective d'entretien

L'examinateur veut vous voir **recourir à la bonne structure de données** plutôt qu'à un `ORDER BY score LIMIT 100` en SQL (qui re-trie à chaque appel et meurt sous la charge d'écriture). Les bonnes réponses nomment le ZSET ; les excellentes couvrent les **requêtes around-me, les égalités, la persistance et la stratégie de sharding**. Un piège classique : oublier que Redis est volatil et le traiter comme la source de vérité — un redémarrage efface le board sauf si AOF/RDB ou un miroir DB existe.

## Compromis et pannes

- **Égalités.** Les scores égaux s'ordonnent lexicographiquement par membre, ce qui semble aléatoire. Encodez un tiebreaker dans le score (par ex. `score * 1e13 - timestamp`) pour que ceux qui ont réussi plus tôt soient mieux classés.
- **Clé chaude.** Un seul ZSET global est une clé sur un shard — un hotspot d'écriture. Bufferisez/batchez les `ZADD`, ou utilisez des boards à buckets temporels (quotidiens/hebdomadaires) pour répartir la charge.
- **Cohérence.** Les lectures peuvent être en retard de secondes sur le miroir DB asynchrone — acceptable pour des leaderboards, pas pour des paiements ; réconciliez depuis Postgres avant d'attribuer des prix.
- **Coût mémoire.** Des millions de membres coûtent de la vraie RAM ; expirez les boards saisonniers avec des TTL.
- **Quand ne pas le faire :** un leaderboard de quelques milliers rafraîchi chaque minute convient comme requête SQL cachée — le ZSET Redis brille quand les écritures sont constantes et que le rang doit être instantané.

Architecture

Comment ça fonctionne

Sharding pour des millions d'utilisateurs

Perspective d'entretien

Compromis et pannes

Questions connexes