¿Cómo manejas 5M de votos en 10 minutos a escala?

Question

IT Interview Practice · Accepted Answer

No escribas cada voto directamente a una fila de base de datos — **bufferiza las escrituras, fragmenta los contadores y acepta un recuento eventual**. 5M de votos en 10 minutos son ~8.300 votos/seg de media, con picos mucho más altos (un momento de TV en vivo puede multiplicarlo por 10). El truco es convertir una actualización caliente de una única fila en muchos incrementos independientes y 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 qué bufferizar las escrituras

Una cola como **Kafka** desacopla la ingesta del recuento. La escritura del cliente es un append barato; si los consumers se quedan atrás durante un pico, los eventos esperan en el log en lugar de saturar la DB. Kafka también da **replay** — si un consumer se cae, reprocesas desde el último offset comprometido sin perder votos.

## Los contadores fragmentados matan el hotspot

Si cada voto para "Opción A" hace `UPDATE counter SET n=n+1 WHERE id='A'`, esa única fila se convierte en un cuello de botella de contención de locks — miles de transacciones se serializan sobre una fila. En su lugar, divide cada opción en **N filas shard** (`A:0 … A:63`). Cada incremento golpea un shard aleatorio, así que las escrituras se reparten entre N filas y corren en paralelo. El total mostrado es `SUM(shards)`, calculado cada segundo o dos por un aggregator. En Redis esto son solo N claves `INCR`; en DynamoDB, N partition keys.

## Dedup de un-voto

Impón "un voto por usuario" con una idempotency key: `SADD voted:{pollId} {userId}` (o un put condicional). Si el usuario ya existe, descarta el evento antes de incrementar. Haz esto en el consumer, no en el cliente — los clientes mienten y reintentan.

## Perspectiva de la entrevista

El entrevistador sondea si reconoces el **problema de la única clave caliente** y recurres a bufferizar + fragmentar en lugar de "añadir más réplicas de DB" (las réplicas escalan lecturas, no esta escritura). Bueno: "usa una cola y una cache." Excelente: nombras la **compensación de eventual consistency** — el número en vivo va un segundo por detrás de la realidad — y argumentas que eso está bien para un conteo de votos pero *no* para el resultado final certificado, que recalculas de forma autoritativa tras el cierre de la votación.

**Trampa común:** usar una transacción de base de datos por voto para lograr "exactitud". A esta escala eso es justo lo que se derrite.

## Compensaciones y modos de fallo

- **Recuento eventual:** las sumas de shards van con retraso; aceptable para un contador en vivo, reconcilia al cierre.
- **Entrega at-least-once:** Kafka puede reentregar — el dedup hace idempotentes los incrementos, de lo contrario cuentas doble.
- **Sesgo de shard caliente:** con muy pocos shards sigues teniendo contención; con demasiados, sumar se vuelve caro. 32–128 shards es lo típico.
- **Equidad/fraude:** rate-limit por IP/dispositivo; el SET de un-voto es tu frontera de integridad. Perderlo significa relleno de urnas, no un crash — posiblemente peor.

Por qué bufferizar las escrituras

Los contadores fragmentados matan el hotspot

Dedup de un-voto

Perspectiva de la entrevista

Compensaciones y modos de fallo

Preguntas relacionadas