Ta yaya za ka sarrafa ƙuri'u miliyan 5 cikin mintuna 10 a babban sikeli?

Question

IT Interview Practice · Accepted Answer

Kada ka rubuta kowace ƙuri'a kai tsaye zuwa row na database — **yi buffer na rubuce-rubuce, yi shard na counters, kuma ka karɓi eventual tally**. Ƙuri'u miliyan 5 cikin mintuna 10 kusan ƙuri'u 8,300 ne a daƙiƙa a matsakaici, tare da spikes masu girma sosai (lokacin live TV na iya ninka wannan sau 10). Dabarar ita ce mai da hot single-row update zuwa increments masu yawa masu zaman kansu, masu daidai.

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

## Me ya sa za a yi buffer na rubuce-rubuce

Queue kamar **Kafka** yana raba ingestion daga tallying. Rubutun client shi ne append mai arha; idan consumers suka koma baya a lokacin spike, events suna jira a log maimakon cika DB. Kafka kuma yana ba da **replay** — idan consumer ya faɗi, kana sake sarrafawa daga last committed offset ba tare da rasa ƙuri'u ba.

## Sharded counters suna kashe hotspot

Idan kowace ƙuri'a ga "Option A" ta yi `UPDATE counter SET n=n+1 WHERE id='A'`, wannan row ɗaya yana zama lock-contention bottleneck — dubban transactions suna serialize a row ɗaya. Maimakon haka, raba kowane option zuwa **N shard rows** (`A:0 … A:63`). Kowane increment yana bugun random shard, don haka rubuce-rubuce suna bazuwa a kan N rows kuma suna gudana daidai. Jimlar da ake nunawa ita ce `SUM(shards)`, wanda aggregator ke ƙididdigewa kowane daƙiƙa ɗaya ko biyu. A Redis wannan `INCR` keys N kawai ne; a DynamoDB, partition keys N.

## One-vote dedup

Tilasta "ƙuri'a ɗaya ga kowane mai amfani" da idempotency key: `SADD voted:{pollId} {userId}` (ko conditional put). Idan mai amfani ya rigaya ya kasance, zubar da event kafin ƙarawa. Yi wannan a consumer, ba client ba — clients suna ƙarya kuma suna retry.

## Ra'ayin hira

Mai yin hirar yana bincike ko ka gane **single-hot-key problem** kuma ka nemi buffering + sharding maimakon "ƙara ƙarin DB replicas" (replicas suna scale reads, ba wannan write ba). Mai kyau: "amfani da queue da cache." Mai kyau sosai: ka ambaci **eventual-consistency trade-off** — lambar live tana bin gaskiya bayan daƙiƙa ɗaya — kuma ka jayayya cewa hakan yayi kyau ga adadin ƙuri'a amma *ba* ga sakamakon ƙarshe da aka tabbatar ba, wanda kake sake ƙididdigewa da iko bayan poll ɗin ya rufe.

**Tarkon gama gari:** amfani da database transaction ga kowace ƙuri'a don "daidaito". A wannan sikeli wannan shi ne abin da ke narkewa.

## Sulhu & hanyoyin gazawa

- **Eventual tally:** shard sums suna bin baya; abin karɓa ga live counter, ka yi sulhu a rufewa.
- **At-least-once delivery:** Kafka na iya redeliver — dedup yana mai da increments idempotent, in ba haka ba za ka ƙidaya sau biyu.
- **Hot shard skew:** shards kaɗan sosai kuma har yanzu kana da contention; da yawa sosai kuma summing ya zama mai tsada. Shards 32–128 na kowa ne.
- **Adalci/zamba:** rate-limit ga kowane IP/device; one-vote SET shi ne integrity boundary. Rasa shi yana nufin ballot stuffing, ba crash ba — wataƙila mafi muni.

Me ya sa za a yi buffer na rubuce-rubuce

Sharded counters suna kashe hotspot

One-vote dedup

Ra'ayin hira

Sulhu & hanyoyin gazawa

Tambayoyi masu alaƙa