1 कोटी timed tasks साठी scheduler तुम्ही कसा डिझाईन कराल?

Question

IT Interview Practice · Accepted Answer

tasks एका **time-bucketed / priority queue** मध्ये due time नुसार keyed करून साठवा, फक्त *आत्ता* due असलेल्या tasks poll करा, आणि त्या **at-least-once** delivery सह idempotent workers ना द्या. दर tick ला 1 कोटी rows कधीही 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 नुसार indexed Task store**: एक Redis sorted set (`ZADD tasks score=due_ts`) किंवा `(run_at)` वर indexed DB table. `ZPOPMIN`/`ZRANGEBYSCORE now` फक्त या सेकंदाला due असलेल्या tasks खेचते — O(log n), table scan नव्हे. task-id नुसार **Sharding/partitioning** 1 कोटी tasks nodes मध्ये पसरवते जेणेकरून कोणतेही एकच store hot नसते.
- **leader election असलेला Poller**: प्रत्येक partition ला etcd/ZooKeeper द्वारे निवडलेला एक active poller असतो; अपयशावर standbys ताबा घेतात. प्रत्येक partition ला एक leader दोन pollers ने एकाच task ला dispatch करणे टाळतो, तर partitioning throughput उच्च ठेवते.
- **Ready queue (Kafka)**: due tasks enqueue होतात, *scheduling* ला *execution* पासून decouple करतात. Workers poller पासून स्वतंत्रपणे scale होतात.
- **Idempotent workers** execute करतात आणि **ack** करतात. delivery at-least-once असल्याने, task दोनदा चालू शकतो (dispatch नंतर done मार्क करण्याआधी poller crash झाला) — म्हणून काम स्वतः `task_id` वर keyed idempotent असले पाहिजे, अन्यथा तुम्ही ग्राहकाला दोनदा charge करता. अपयश backoff सह retry होतात, नंतर DLQ मध्ये जातात.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा दोन गोष्टी तपासतो: **efficient time lookup** आणि **exactly-once vs at-least-once**. "चांगले" म्हणजे table वर cron loop; "उत्तम" म्हणजे sorted-set index अधिक हा प्रामाणिक कबुलीजबाब की distributed exactly-once अव्यवहार्य आहे, म्हणून तुम्ही **at-least-once + idempotent workers** निवडता. एक classic सापळा: एका scheduler node वर अवलंबून राहणे — तो SPOF आणि throughput छत आहे. दुसरा: खूप coarse (दर मिनिट) poll करणे जेव्हा tasks ना सेकंद precision लागते, किंवा खूप fine करून store ला hammer करणे.

## तडजोडी आणि अपयश

- **Precision vs load**: 1s tick सेकंद-पातळीची accuracy देते पण जास्त polls; scan cost कमी करण्यासाठी tasks ना per-minute नंतर per-second sub-queues मध्ये bucket करा (Kafka आणि Quartz वापरणारा "timing wheel" / hashed-wheel दृष्टिकोन).
- **At-least-once vs exactly-once**: crash boundary पलीकडे खरी exactly-once मिळत नाही; idempotency keys double execution निरुपद्रवी करतात — योग्य तडजोड.
- **अपयश**: dispatch च्या मध्ये poller मेल्यास leader election एक standby ला promote करते आणि un-acked tasks पुन्हा deliver होतात — काहीही हरवत नाही, काही पुन्हा होऊ शकतात. nodes मधील **clock skew** (NTP) कडे लक्ष द्या अन्यथा tasks लवकर/उशिरा fire होतात; आणि retries cap करा जेणेकरून कायमचे अपयशी task अनंतकाळ loop करत नाही — तपासणीसाठी DLQ कडे पाठवा.

आर्किटेक्चर

घटक आणि प्रवाह

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

संबंधित प्रश्न