Como você lida com 5M de votos em 10 minutos em escala?

Question

IT Interview Practice · Accepted Answer

Não grave cada voto direto em uma linha de banco de dados — **bufferize as escritas, faça sharding dos contadores e aceite a contagem eventual**. 5M de votos em 10 minutos são ~8.300 votos/seg em média, com picos muito maiores (um momento de TV ao vivo pode fazer 10x disso). O truque é transformar um update de linha única quente em muitos incrementos independentes e paralelos.

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

## Por que bufferizar as escritas

Uma fila como **Kafka** desacopla a ingestão da contagem. A escrita do cliente é um append barato; se os consumidores ficarem para trás durante um pico, os eventos esperam no log em vez de sobrecarregar o DB. O Kafka também dá **replay** — se um consumidor cai, você reprocessa a partir do último offset comitado sem perder votos.

## Contadores com sharding eliminam o hotspot

Se cada voto em "Opção A" faz `UPDATE counter SET n=n+1 WHERE id='A'`, essa única linha vira um gargalo de contenção de lock — milhares de transações serializam em uma linha. Em vez disso, divida cada opção em **N linhas de shard** (`A:0 … A:63`). Cada incremento acerta um shard aleatório, então as escritas se espalham por N linhas e rodam em paralelo. O total exibido é `SUM(shards)`, calculado a cada um ou dois segundos por um agregador. No Redis isso são apenas N chaves `INCR`; no DynamoDB, N partition keys.

## Dedup de um voto

Imponha "um voto por usuário" com uma chave de idempotência: `SADD voted:{pollId} {userId}` (ou um put condicional). Se o usuário já existir, descarte o evento antes de incrementar. Faça isso no consumidor, não no cliente — clientes mentem e fazem retry.

## Perspectiva de entrevista

O entrevistador está sondando se você reconhece o **problema da chave única quente** e recorre a buffering + sharding em vez de "adicionar mais réplicas de DB" (réplicas escalam leituras, não esta escrita). Bom: "usar uma fila e um cache." Excelente: você nomeia o **trade-off de consistência eventual** — o número ao vivo atrasa a realidade por um segundo — e argumenta que isso é aceitável para uma contagem de votos, mas *não* para o resultado final certificado, que você recalcula de forma autoritativa depois que a votação fecha.

**Armadilha comum:** usar uma transação de banco por voto por "precisão". Nessa escala, é exatamente isso que derrete.

## Trade-offs e modos de falha

- **Contagem eventual:** as somas de shard atrasam; aceitável para um contador ao vivo, reconcilie no fechamento.
- **Entrega at-least-once:** o Kafka pode reentregar — o dedup torna os incrementos idempotentes, senão você conta em duplicidade.
- **Skew de shard quente:** shards de menos e você ainda contende; de mais e somar fica caro. 32–128 shards é o típico.
- **Justiça/fraude:** rate-limit por IP/dispositivo; o SET de um-voto é sua fronteira de integridade. Perdê-lo significa fraude eleitoral (ballot stuffing), não um crash — indiscutivelmente pior.

Por que bufferizar as escritas

Contadores com sharding eliminam o hotspot

Dedup de um voto

Perspectiva de entrevista

Trade-offs e modos de falha

Perguntas relacionadas