آپ بڑے پیمانے پر 10 منٹ میں 50 لاکھ votes کیسے سنبھالتے ہیں؟

Question

IT Interview Practice · Accepted Answer

ہر vote کو براہِ راست database row میں نہ لکھیں — **writes کو buffer کریں، counters کو shard کریں، اور eventual tally قبول کریں**۔ 10 منٹ میں 50 لاکھ votes اوسطاً تقریباً 8,300 votes/sec ہیں، جن میں spikes کہیں زیادہ ہوتے ہیں (ایک live TV لمحہ اسے 10 گنا کر سکتا ہے)۔ کمال یہ ہے کہ ایک hot single-row update کو کئی آزاد، متوازی increments میں بدل دیا جائے۔

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

## writes کو buffer کیوں کریں

**Kafka** جیسی queue ingestion کو tallying سے decouple کرتی ہے۔ client write ایک سستا append ہے؛ اگر spike کے دوران consumers پیچھے رہ جائیں تو events DB کو مغلوب کرنے کے بجائے log میں انتظار کرتے ہیں۔ Kafka **replay** بھی دیتی ہے — اگر consumer crash ہو جائے تو آپ آخری committed offset سے دوبارہ process کرتے ہیں بغیر votes کھوئے۔

## Sharded counters hotspot کو ختم کرتے ہیں

اگر "Option A" کے ہر vote پر `UPDATE counter SET n=n+1 WHERE id='A'` ہو تو وہ ایک row lock-contention bottleneck بن جاتی ہے — ہزاروں transactions ایک ہی row پر serialize ہو جاتے ہیں۔ اس کے بجائے، ہر option کو **N shard rows** (`A:0 … A:63`) میں تقسیم کریں۔ ہر increment ایک random shard کو hit کرتا ہے، لہٰذا writes N rows میں پھیلتی ہیں اور متوازی چلتی ہیں۔ دکھایا گیا total `SUM(shards)` ہے، جو ایک aggregator ہر ایک دو سیکنڈ میں compute کرتا ہے۔ Redis میں یہ صرف N `INCR` keys ہیں؛ DynamoDB میں، N partition keys۔

## One-vote dedup

"فی صارف ایک vote" کو ایک idempotency key سے نافذ کریں: `SADD voted:{pollId} {userId}` (یا ایک conditional put)۔ اگر صارف پہلے سے موجود ہے، تو increment سے پہلے event drop کر دیں۔ یہ consumer میں کریں، client میں نہیں — clients جھوٹ بولتے ہیں اور retry کرتے ہیں۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ آپ **single-hot-key problem** کو پہچانتے ہیں اور "مزید DB replicas شامل کرو" کے بجائے buffering + sharding کی طرف بڑھتے ہیں (replicas reads scale کرتے ہیں، یہ write نہیں)۔ اچھا: "ایک queue اور ایک cache استعمال کرو۔" عمدہ: آپ **eventual-consistency trade-off** کا نام لیتے ہیں — live نمبر حقیقت سے ایک سیکنڈ پیچھے رہتا ہے — اور دلیل دیتے ہیں کہ یہ vote count کے لیے ٹھیک ہے مگر *حتمی certified نتیجے* کے لیے نہیں، جسے آپ poll بند ہونے کے بعد authoritatively دوبارہ compute کرتے ہیں۔

**عام جال:** "درستگی" کے لیے فی vote ایک database transaction استعمال کرنا۔ اس پیمانے پر یہی چیز پگھلتی ہے۔

## توازن اور ناکامی کے طریقے

- **Eventual tally:** shard sums پیچھے رہتے ہیں؛ ایک live counter کے لیے قابلِ قبول، بند ہونے پر reconcile کریں۔
- **At-least-once delivery:** Kafka دوبارہ deliver کر سکتی ہے — dedup increments کو idempotent بناتی ہے، ورنہ آپ دوہرا گنتے ہیں۔
- **Hot shard skew:** بہت کم shards اور آپ اب بھی contend کرتے ہیں؛ بہت زیادہ اور summing مہنگا ہو جاتا ہے۔ 32–128 shards عام ہیں۔
- **انصاف/دھوکہ:** فی IP/device rate-limit کریں؛ one-vote SET آپ کی integrity boundary ہے۔ اسے کھونے کا مطلب ballot stuffing ہے، crash نہیں — جو دلیلاً بدتر ہے۔

writes کو buffer کیوں کریں

Sharded counters hotspot کو ختم کرتے ہیں

One-vote dedup

انٹرویو کا نقطۂ نظر

توازن اور ناکامی کے طریقے

متعلقہ سوالات