Diseña un leaderboard en tiempo real para millones de jugadores

Question

IT Interview Practice · Accepted Answer

**Usa un sorted set (ZSET) de Redis indexado por score: el rank y el top-N se convierten en operaciones integradas O(log N), así que nunca ordenas millones de filas por request.** Un ZSET mantiene a los miembros ordenados por score automáticamente; eso es exactamente lo que es un leaderboard.

## Arquitectura

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

## Cómo funciona

- **ZADD** hace upsert del score de un jugador en O(log N). Redis mantiene el orden vía una **skip list**, así que no se necesita re-ordenar.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` devuelve el top 100 en O(log N + 100).
- **Tu rank**: `ZREVRANK board user` da la posición basada en 0; **around-me** es `ZREVRANGE rank-5 rank+5` — la porción de jugadores cercanos a ti.
- **Durabilidad**: Redis es en memoria. Habilita **AOF** (append-only file) para replay, y refleja los scores asíncronamente en **Postgres** como el verdadero system of record, para que una pérdida de Redis sea recuperable.

## Sharding para millones de usuarios

Un ZSET alberga decenas de millones de miembros sin problema (limitado por memoria, ~100MB para 1M de entradas). Más allá de eso, o para escala global, **fragmenta por rango de score** (0–1k, 1k–10k…) para que cada shard sea una banda contigua — un top-N global lee solo el shard superior. Evita fragmentar por hash de usuario: recombinar ranks entre shards aleatorios es caro.

## Perspectiva de la entrevista

El entrevistador quiere verte **recurrir a la estructura de datos correcta** en lugar de `ORDER BY score LIMIT 100` en SQL (que re-ordena en cada golpe y muere bajo carga de escritura). Las buenas respuestas nombran ZSET; las excelentes cubren **queries around-me, empates, persistencia y estrategia de shard**. Una trampa clásica: olvidar que Redis es volátil y tratarlo como el source of truth — un reinicio borra el tablero salvo que exista AOF/RDB o un espejo en DB.

## Compensaciones y modos de fallo

- **Empates.** Los scores iguales se ordenan lexicográficamente por miembro, lo que parece aleatorio. Codifica un tiebreaker en el score (p. ej. `score * 1e13 - timestamp`) para que quienes lo lograron antes ranqueen más alto.
- **Clave caliente.** Un único ZSET global es una clave en un shard — un hotspot de escritura. Bufferiza/agrupa los `ZADD`, o usa tableros con buckets temporales (diario/semanal) para repartir la carga.
- **Consistencia.** Las lecturas pueden ir con retraso respecto al espejo async en DB por segundos — bien para leaderboards, no para pagos; reconcilia desde Postgres antes de otorgar premios.
- **Coste de memoria.** Millones de miembros cuestan RAM real; expira los tableros de temporada con TTLs.
- **Cuándo no:** un leaderboard de unos pocos miles refrescado cada minuto está bien como una query SQL cacheada — el ZSET de Redis brilla cuando las escrituras son constantes y el rank debe ser instantáneo.

Arquitectura

Cómo funciona

Sharding para millones de usuarios

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas