Come gestisci 5M di voti in 10 minuti su larga scala?

Question

IT Interview Practice · Accepted Answer

Non scrivere ogni voto direttamente in una riga di database: **bufferizza le scritture, fai sharding dei contatori e accetta un conteggio eventuale**. 5M di voti in 10 minuti sono ~8.300 voti/sec in media, con picchi molto più alti (un momento TV in diretta può decuplicarli). Il trucco è trasformare un aggiornamento su una singola riga calda in molti incrementi indipendenti e paralleli.

```text
Client ─▶ Edge/API ─▶ Kafka (vote events) ─▶ Consumers ─┬─▶ Dedup store (SET one-vote)
                        (durable buffer)                 └─▶ Sharded counters (INCR N shards)
                                                                     │
Redis/Aggregator ◀── periodic sum of shards ──────────────────────┘
      │
      └─▶ Read replica / CDN cache ─▶ Live tally to clients
```

## Perché bufferizzare le scritture

Una coda come **Kafka** disaccoppia l'ingestione dal conteggio. La scrittura del client è un append economico; se i consumer restano indietro durante un picco, gli eventi attendono nel log invece di sopraffare il DB. Kafka offre anche il **replay**: se un consumer va in crash, riprocessi dall'ultimo offset committato senza perdere voti.

## I contatori sharded eliminano l'hotspot

Se ogni voto per "Opzione A" fa `UPDATE counter SET n=n+1 WHERE id='A'`, quella singola riga diventa un collo di bottiglia da contesa sui lock — migliaia di transazioni si serializzano su una riga. Invece, dividi ogni opzione in **N righe shard** (`A:0 … A:63`). Ogni incremento colpisce uno shard casuale, così le scritture si distribuiscono su N righe e girano in parallelo. Il totale mostrato è `SUM(shards)`, calcolato ogni secondo o due da un aggregatore. In Redis sono semplicemente N chiavi `INCR`; in DynamoDB, N partition key.

## Dedup one-vote

Imponi "un voto per utente" con una idempotency key: `SADD voted:{pollId} {userId}` (o un conditional put). Se l'utente esiste già, scarta l'evento prima di incrementare. Fallo nel consumer, non nel client: i client mentono e ritentano.

## Prospettiva del colloquio

L'intervistatore verifica se riconosci il **problema della singola chiave calda** e ricorri a buffering + sharding invece di "aggiungi più replica al DB" (le replica scalano le letture, non questa scrittura). Buono: "usa una coda e una cache." Eccellente: nomini il **compromesso sulla consistenza eventuale** — il numero live è indietro rispetto alla realtà di un secondo — e argomenti che va bene per un conteggio di voti ma *non* per il risultato finale certificato, che ricalcoli in modo autorevole dopo la chiusura del sondaggio.

**Trappola comune:** usare una transazione di database per ogni voto per "accuratezza". A questa scala è proprio ciò che collassa.

## Compromessi e modalità di guasto

- **Conteggio eventuale:** le somme degli shard sono in ritardo; accettabile per un contatore live, riconcilia alla chiusura.
- **Consegna at-least-once:** Kafka può riconsegnare — la dedup rende gli incrementi idempotenti, altrimenti conti due volte.
- **Skew dello shard caldo:** troppi pochi shard e c'è ancora contesa; troppi e la somma diventa costosa. 32–128 shard è tipico.
- **Correttezza/frode:** rate-limit per IP/dispositivo; il SET one-vote è il tuo confine di integrità. Perderlo significa ballot stuffing, non un crash — probabilmente peggio.

Perché bufferizzare le scritture

I contatori sharded eliminano l'hotspot

Dedup one-vote

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate