Как обработать 5 млн голосов за 10 минут на масштабе?

Question

IT Interview Practice · Accepted Answer

Не пишите каждый голос напрямую в строку базы данных — **буферизуйте записи, шардируйте счётчики и принимайте eventual-подсчёт**. 5 млн голосов за 10 минут — это в среднем ~8 300 голосов/с, с пиками намного выше (момент прямого эфира может дать 10-кратный всплеск). Трюк в том, чтобы превратить обновление одной горячей строки во множество независимых параллельных инкрементов.

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

## Зачем буферизовать записи

Очередь вроде **Kafka** отделяет приём от подсчёта. Запись клиента — это дешёвый append; если consumer-ы отстают на всплеске, события ждут в логе, а не захлёстывают БД. Kafka также даёт **replay** — если consumer падает, вы переобрабатываете с последнего закоммиченного offset без потери голосов.

## Шардированные счётчики убивают hotspot

Если каждый голос за «Option A» делает `UPDATE counter SET n=n+1 WHERE id='A'`, эта единственная строка становится узким местом по конкуренции блокировок — тысячи транзакций сериализуются на одной строке. Вместо этого разбейте каждую опцию на **N строк-шардов** (`A:0 … A:63`). Каждый инкремент попадает в случайный шард, так что записи распределяются по N строкам и идут параллельно. Отображаемый итог — это `SUM(shards)`, вычисляемый агрегатором каждые секунду-две. В Redis это просто N ключей `INCR`; в DynamoDB — N partition-ключей.

## Дедупликация «один голос»

Обеспечьте «один голос на пользователя» ключом идемпотентности: `SADD voted:{pollId} {userId}` (или условный put). Если пользователь уже есть, отбросьте событие до инкремента. Делайте это в consumer-е, а не в клиенте — клиенты лгут и повторяют.

## Взгляд с точки зрения интервью

Интервьюер прощупывает, узнаёте ли вы **проблему единственного горячего ключа** и тянетесь ли к буферизации + шардированию, а не к «добавить ещё реплик БД» (реплики масштабируют чтения, а не эту запись). Хорошо: «использовать очередь и кэш». Отлично: вы называете **компромисс eventual-consistency** — живое число отстаёт от реальности на секунду — и доказываете, что для счёта голосов это нормально, но *не* для итогового сертифицированного результата, который вы авторитетно пересчитываете после закрытия голосования.

**Частая ловушка:** транзакция БД на каждый голос ради «точности». На таком масштабе именно это и плавится.

## Компромиссы и режимы отказа

- **Eventual-подсчёт:** суммы шардов отстают; приемлемо для живого счётчика, сверяйтесь при закрытии.
- **Доставка at-least-once:** Kafka может переотправить — дедупликация делает инкременты идемпотентными, иначе вы задваиваете.
- **Перекос горячего шарда:** слишком мало шардов — всё ещё конкуренция; слишком много — суммирование дорожает. Типично 32–128 шардов.
- **Честность/фрод:** rate-limit по IP/устройству; SET «один голос» — ваша граница целостности. Потеря его означает вброс бюллетеней, а не падение — что, пожалуй, хуже.

Зачем буферизовать записи

Шардированные счётчики убивают hotspot

Дедупликация «один голос»

Взгляд с точки зрения интервью

Компромиссы и режимы отказа

Похожие вопросы