১০ মিনিটে ৫০ লক্ষ vote কীভাবে scale-এ সামলাবেন?

Question

IT Interview Practice · Accepted Answer

প্রতিটি vote সরাসরি একটি database row-তে লিখবেন না — **write buffer করুন, counter shard করুন, এবং eventual tally মেনে নিন**। ১০ মিনিটে ৫০ লক্ষ vote গড়ে ~৮,৩০০ vote/sec, spike অনেক বেশি (একটি live TV মুহূর্ত এটিকে ১০x করতে পারে)। কৌশলটি হলো একটি hot single-row update-কে অনেক স্বাধীন, সমান্তরাল increment-এ রূপান্তরিত করা।

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

## কেন write buffer করবেন

**Kafka**-এর মতো একটি queue ingestion-কে tallying থেকে decouple করে। client write একটি সস্তা append; spike-এর সময় consumer পিছিয়ে পড়লে event DB-কে অভিভূত করার বদলে log-এ অপেক্ষা করে। Kafka **replay**-ও দেয় — একটি consumer crash করলে আপনি vote না হারিয়ে শেষ committed offset থেকে পুনরায় process করেন।

## Sharded counter hotspot নিধন করে

"Option A"-এর প্রতিটি vote যদি `UPDATE counter SET n=n+1 WHERE id='A'` করে, সেই একটি row একটি lock-contention bottleneck হয়ে যায় — হাজার হাজার transaction একটি row-তে serialize হয়। বরং, প্রতিটি option-কে **N shard row**-তে (`A:0 … A:63`) ভাগ করুন। প্রতিটি increment একটি random shard-এ আঘাত করে, তাই write N row জুড়ে ছড়ায় এবং সমান্তরালে চলে। প্রদর্শিত total হলো `SUM(shards)`, প্রতি সেকেন্ড বা দুই-এ একটি aggregator দ্বারা গণনা করা। Redis-এ এটি কেবল N `INCR` key; DynamoDB-তে, N partition key।

## One-vote dedup

একটি idempotency key দিয়ে "প্রতি ইউজারে এক vote" প্রয়োগ করুন: `SADD voted:{pollId} {userId}` (বা একটি conditional put)। ইউজার ইতিমধ্যে থাকলে, increment করার আগে event drop করুন। এটি consumer-এ করুন, client-এ নয় — client মিথ্যা বলে এবং retry করে।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার যাচাই করছেন আপনি **single-hot-key সমস্যা** চিনে "আরও DB replica যোগ করুন"-এর বদলে buffering + sharding-এর দিকে হাত বাড়ান কিনা (replica read scale করে, এই write নয়)। ভালো: "একটি queue ও একটি cache ব্যবহার করুন।" দারুণ: আপনি **eventual-consistency trade-off** নাম ধরে বলেন — live সংখ্যাটি বাস্তবতা থেকে এক সেকেন্ড পিছিয়ে — এবং যুক্তি দেন যে একটি vote count-এর জন্য এটি ঠিক আছে, কিন্তু *চূড়ান্ত certified ফলাফলের* জন্য নয়, যেটি আপনি poll বন্ধ হওয়ার পর authoritatively পুনরায় গণনা করেন।

**সাধারণ ফাঁদ:** "নির্ভুলতার" জন্য প্রতি vote-এ একটি database transaction ব্যবহার করা। এই স্কেলে সেটিই গলে যায়।

## ট্রেড-অফ ও ব্যর্থতার ধরন

- **Eventual tally:** shard sum পিছিয়ে থাকে; একটি live counter-এর জন্য গ্রহণযোগ্য, বন্ধ হওয়ার সময় reconcile করুন।
- **At-least-once delivery:** Kafka redeliver করতে পারে — dedup increment-কে idempotent করে, নইলে আপনি double-count করবেন।
- **Hot shard skew:** খুব কম shard আর আপনি এখনও contend করবেন; খুব বেশি আর summing ব্যয়বহুল হয়। ৩২–১২৮ shard সাধারণ।
- **Fairness/fraud:** প্রতি IP/device rate-limit করুন; one-vote SET হলো আপনার integrity boundary। এটি হারানো মানে ballot stuffing, একটি crash নয় — যুক্তিযুক্তভাবে আরও খারাপ।

কেন write buffer করবেন

Sharded counter hotspot নিধন করে

One-vote dedup

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতার ধরন

সম্পর্কিত প্রশ্ন