১ কোটি timed task-এর জন্য একটি scheduler কীভাবে ডিজাইন করবেন?

Question

IT Interview Practice · Accepted Answer

task-গুলোকে due time দিয়ে key করা একটি **time-bucketed / priority queue**-তে সংরক্ষণ করুন, কেবল *এখন* due task-গুলো poll করুন, এবং **at-least-once** delivery সহ idempotent worker-দের কাছে হস্তান্তর করুন। প্রতি tick-এ কখনও ১ কোটি row scan করবেন না — fire time দিয়ে index করুন যাতে প্রতিটি poll কেবল যা due তাকেই স্পর্শ করে।

## আর্কিটেকচার

```text
API ─▶ Task store (DB/Redis ZSET, score = due_ts)  ── 10M tasks, sharded
             │
     Poller (leader per partition) ── ZPOPMIN due<=now ──▶ Ready queue (Kafka)
             │ leader election (etcd/ZK)                       │
             ▼                                                 ▼
     other pollers idle/standby                       Worker pool (idempotent)
                                                        └─ ack ✔ / retry ✖ ─▶ DLQ
```

## কম্পোনেন্ট ও ফ্লো

- **fire time দিয়ে index করা task store**: একটি Redis sorted set (`ZADD tasks score=due_ts`) বা `(run_at)`-এ index করা একটি DB table। `ZPOPMIN`/`ZRANGEBYSCORE now` কেবল এই সেকেন্ডে due task টানে — O(log n), table scan নয়। task-id দিয়ে **Sharding/partitioning** ১ কোটি task-কে node জুড়ে ছড়িয়ে দেয় যাতে কোনো একক store hot না হয়।
- **leader election সহ Poller**: প্রতিটি partition-এর etcd/ZooKeeper দিয়ে নির্বাচিত একটি active poller থাকে; failure-এ standby দখল নেয়। প্রতি partition-এ একটি leader দুটি poller-কে একই task dispatch করা এড়ায়, আর partitioning throughput উঁচু রাখে।
- **Ready queue (Kafka)**: due task enqueue হয়, *scheduling*-কে *execution* থেকে decouple করে। worker poller থেকে স্বাধীনভাবে scale করে।
- **Idempotent worker** execute করে এবং **ack** করে। যেহেতু delivery at-least-once, একটি task দুবার চলতে পারে (poller dispatch-এর পর, done চিহ্নিত করার আগে crash করেছে) — তাই কাজটি নিজেই অবশ্যই idempotent হতে হবে, `task_id`-তে key করা, নইলে আপনি একজন গ্রাহককে double-charge করবেন। Failure backoff সহ retry হয়, তারপর একটি DLQ-তে নামে।

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

ইন্টারভিউয়ার দুটি জিনিস যাচাই করেন: **দক্ষ time lookup** এবং **exactly-once বনাম at-least-once**। "ভালো" হলো একটি table-এর উপর একটি cron loop; "দারুণ" হলো sorted-set index প্লাস সৎ স্বীকৃতি যে distributed exactly-once অবাস্তব, তাই আপনি **at-least-once + idempotent worker** বাছেন। একটি ক্লাসিক ফাঁদ: একটি একক scheduler node-এর উপর নির্ভর করা — এটি একটি SPOF এবং একটি throughput ceiling। আরেকটি: task-এর সেকেন্ড নির্ভুলতা প্রয়োজন হলে খুব মোটাভাবে (প্রতি মিনিটে) poll করা, অথবা খুব সূক্ষ্মভাবে করে store-এ হাতুড়ি চালানো।

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

- **নির্ভুলতা বনাম load**: ১সে tick সেকেন্ড-স্তরের নির্ভুলতা দেয় কিন্তু বেশি poll; scan খরচ কমাতে task-কে per-minute তারপর per-second sub-queue-তে bucket করুন (Kafka ও Quartz-এ ব্যবহৃত "timing wheel" / hashed-wheel পদ্ধতি)।
- **At-least-once বনাম exactly-once**: একটি crash boundary জুড়ে আপনি সত্যিকারের exactly-once পেতে পারেন না; idempotency key double execution-কে নিরীহ করে তোলে — সঠিক trade।
- **Failure**: একটি poller dispatch-এর মাঝপথে মরলে, leader election একটি standby-কে promote করে এবং un-acked task redeliver হয় — কিছুই হারায় না, কিছু পুনরায় হতে পারে। node জুড়ে **clock skew** (NTP) খেয়াল রাখুন নইলে task আগে/পরে fire হয়; এবং retry cap করুন যাতে একটি চিরস্থায়ীভাবে ব্যর্থ task চিরকাল loop না করে — এটিকে পরিদর্শনের জন্য DLQ-তে পাঠান।

আর্কিটেকচার

কম্পোনেন্ট ও ফ্লো

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

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

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