Ölçekte 10 dakikada 5 milyon oyu nasıl ele alırsınız?

Question

IT Interview Practice · Accepted Answer

Her oyu doğrudan bir veritabanı satırına yazmayın — bunun yerine **yazmaları buffer'layın, sayaçları shard'layın ve eventual tally'yi kabul edin**. 10 dakikada 5 milyon oy ortalama ~8.300 oy/sn'dir, çok daha yüksek spike'larla (canlı bir TV anı bunu 10 katına çıkarabilir). Hile, hot bir single-row güncellemesini birçok bağımsız, paralel artışa dönüştürmektir.

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

## Yazmaları neden buffer'lamalı

**Kafka** gibi bir kuyruk, ingestion'ı tally'den decouple eder. Client yazması ucuz bir append'tir; consumer'lar bir spike sırasında geride kalırsa, olaylar DB'yi ezmek yerine log'da bekler. Kafka ayrıca **replay** verir — bir consumer çökerse, oyları kaybetmeden son commit edilen offset'ten yeniden işlersiniz.

## Sharded counter'lar hotspot'u öldürür

"Option A" için her oy `UPDATE counter SET n=n+1 WHERE id='A'` yaparsa, o tek satır bir lock-contention bottleneck'i haline gelir — binlerce transaction tek bir satır üzerinde serileşir. Bunun yerine, her seçeneği **N shard satırına** bölün (`A:0 … A:63`). Her artış rastgele bir shard'a çarpar, böylece yazmalar N satır üzerine yayılır ve paralel çalışır. Gösterilen toplam `SUM(shards)`'tır, her bir iki saniyede bir bir aggregator tarafından hesaplanır. Redis'te bu sadece N `INCR` key'idir; DynamoDB'de N partition key'i.

## Tek oy dedup

"Kullanıcı başına bir oy"u bir idempotency key ile zorlayın: `SADD voted:{pollId} {userId}` (veya bir conditional put). Kullanıcı zaten varsa, artırmadan önce olayı düşürün. Bunu client'ta değil, consumer'da yapın — client'lar yalan söyler ve yeniden dener.

## Mülakat perspektifi

Mülakatı yapan kişi, **single-hot-key problemini** fark edip "daha fazla DB replica ekle" yerine buffering + sharding'e başvurup vurmadığınızı yokluyor (replica'lar okumaları ölçekler, bu yazmayı değil). İyi: "bir kuyruk ve bir cache kullan." Harika: **eventual-consistency ödünleşimini** adlandırırsınız — canlı sayı gerçeğin bir saniye gerisinde kalır — ve bunun bir oy sayımı için sorun olmadığını, ancak poll kapandıktan sonra otoriter olarak yeniden hesapladığınız *final onaylı sonuç* için sorun olduğunu savunursunuz.

**Yaygın tuzak:** "doğruluk" için oy başına bir veritabanı transaction'ı kullanmak. Bu ölçekte eriyen şey budur.

## Ödünleşimler ve hata modları

- **Eventual tally:** shard toplamları gecikir; canlı bir sayaç için kabul edilebilir, kapanışta mutabakat yapın.
- **At-least-once teslimat:** Kafka yeniden teslim edebilir — dedup artışları idempotent yapar, aksi halde çift sayarsınız.
- **Hot shard skew:** çok az shard ve hala çekişirsiniz; çok fazla ve toplama pahalılaşır. 32–128 shard tipiktir.
- **Adalet/dolandırıcılık:** IP/cihaz başına rate-limit; tek oy SET'i bütünlük sınırınızdır. Onu kaybetmek bir çökme değil, oy pusulası doldurma anlamına gelir — muhtemelen daha kötü.

Yazmaları neden buffer'lamalı

Sharded counter'lar hotspot'u öldürür

Tek oy dedup

Mülakat perspektifi

Ödünleşimler ve hata modları

İlgili sorular