Progetta una leaderboard in tempo reale per milioni di giocatori

Question

IT Interview Practice · Accepted Answer

**Usa un sorted set (ZSET) di Redis indicizzato per punteggio: rank e top-N diventano operazioni integrate O(log N), così non ordini mai milioni di righe per richiesta.** Uno ZSET mantiene i membri ordinati per punteggio automaticamente; è esattamente ciò che una leaderboard è.

## Architettura

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

## Come funziona

- **ZADD** fa upsert del punteggio di un giocatore in O(log N). Redis mantiene l'ordine tramite una **skip list**, quindi non serve alcun re-sort.
- **Top-N**: `ZREVRANGE board 0 99 WITHSCORES` restituisce i primi 100 in O(log N + 100).
- **Il tuo rank**: `ZREVRANK board user` dà la posizione a base 0; **around-me** è `ZREVRANGE rank-5 rank+5` — la fetta di giocatori vicini a te.
- **Durabilità**: Redis è in memoria. Abilita **AOF** (append-only file) per il replay, e specchia i punteggi in modo asincrono su **Postgres** come vero system of record, così una perdita di Redis è recuperabile.

## Sharding per milioni di utenti

Un singolo ZSET regge tranquillamente decine di milioni di membri (memory-bound, ~100MB per 1M di voci). Oltre a ciò, o per scala globale, **fai sharding per range di punteggio** (0–1k, 1k–10k…) così che ogni shard sia una banda contigua — un top-N globale legge solo lo shard superiore. Evita lo sharding per hash dell'utente: ricombinare i rank tra shard casuali è costoso.

## Prospettiva del colloquio

L'intervistatore vuole vederti **ricorrere alla struttura dati giusta** invece di un `ORDER BY score LIMIT 100` su SQL (che riordina a ogni hit e muore sotto carico di scrittura). Le buone risposte nominano lo ZSET; le eccellenti coprono **query around-me, pareggi, persistenza e strategia di shard**. Una trappola classica: dimenticare che Redis è volatile e trattarlo come fonte di verità — un restart cancella la board a meno che non esistano AOF/RDB o un mirror sul DB.

## Compromessi e modalità di guasto

- **Pareggi.** I punteggi uguali si ordinano lessicograficamente per membro, il che sembra casuale. Codifica un tiebreaker nel punteggio (es. `score * 1e13 - timestamp`) così che chi ha ottenuto il punteggio prima sia posizionato più in alto.
- **Hot key.** Un singolo ZSET globale è una chiave su uno shard — un hotspot di scrittura. Bufferizza/fai batch degli `ZADD`, o usa board a bucket temporali (giornaliera/settimanale) per distribuire il carico.
- **Consistenza.** Le letture possono essere indietro di secondi rispetto al mirror asincrono sul DB — va bene per le leaderboard, non per i payout; riconcilia da Postgres prima di assegnare premi.
- **Costo di memoria.** Milioni di membri costano RAM reale; fai scadere le board stagionali con TTL.
- **Quando non farlo:** una leaderboard di poche migliaia aggiornata ogni minuto va bene come query SQL in cache — lo ZSET di Redis brilla quando le scritture sono costanti e il rank deve essere istantaneo.

Architettura

Come funziona

Sharding per milioni di utenti

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate