Projete um leaderboard em tempo real para milhões de jogadores

Question

IT Interview Practice · Accepted Answer

**Use um sorted set (ZSET) do Redis indexado pelo score: rank e top-N se tornam operações O(log N) embutidas, então você nunca ordena milhões de linhas por requisição.** Um ZSET mantém os membros ordenados por score automaticamente; é exatamente isso que um leaderboard é.

## Arquitetura

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

## Como funciona

- **ZADD** faz upsert do score de um jogador em O(log N). O Redis mantém a ordem via uma **skip list**, então nenhuma reordenação é necessária.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` retorna os 100 melhores em O(log N + 100).
- **Seu rank**: `ZREVRANK board user` dá a posição base-0; **around-me** é `ZREVRANGE rank-5 rank+5` — a fatia de jogadores perto de você.
- **Durabilidade**: o Redis é em memória. Habilite **AOF** (append-only file) para replay, e espelhe os scores de forma assíncrona no **Postgres** como o verdadeiro sistema de registro, para que uma perda do Redis seja recuperável.

## Sharding para milhões de usuários

Um único ZSET guarda dezenas de milhões de membros tranquilamente (limitado por memória, ~100MB para 1M de entradas). Além disso, ou para escala global, **faça sharding por faixa de score** (0–1k, 1k–10k…) para que cada shard seja uma banda contígua — um top-N global lê apenas o shard do topo. Evite sharding por hash de usuário: recombinar ranks entre shards aleatórios é caro.

## Perspectiva de entrevista

O entrevistador quer ver você **recorrer à estrutura de dados certa** em vez de `ORDER BY score LIMIT 100` no SQL (que reordena a cada hit e morre sob carga de escrita). Boas respostas nomeiam ZSET; respostas excelentes cobrem **consultas around-me, empates, persistência e estratégia de shard**. Uma armadilha clássica: esquecer que o Redis é volátil e tratá-lo como a fonte de verdade — um restart limpa o board a menos que AOF/RDB ou um espelho de DB exista.

## Trade-offs e falhas

- **Empates.** Scores iguais ordenam por membro lexicograficamente, o que parece aleatório. Codifique um tiebreaker no score (ex. `score * 1e13 - timestamp`) para que quem conquistou primeiro fique melhor rankeado.
- **Chave quente.** Um único ZSET global é uma chave em um shard — um hotspot de escrita. Bufferize/agrupe os `ZADD`s, ou use boards divididos por tempo (diário/semanal) para espalhar a carga.
- **Consistência.** Leituras podem atrasar em relação ao espelho de DB assíncrono por segundos — ok para leaderboards, não para pagamentos; reconcilie a partir do Postgres antes de conceder prêmios.
- **Custo de memória.** Milhões de membros custam RAM real; expire boards sazonais com TTLs.
- **Quando não usar:** um leaderboard de alguns milhares atualizado a cada minuto está bem como uma consulta SQL cacheada — o ZSET do Redis brilha quando as escritas são constantes e o rank precisa ser instantâneo.

Arquitetura

Como funciona

Sharding para milhões de usuários

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas