1 करोड समयबद्ध 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 मा 1 करोड 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` ले यो second मा due भएका task मात्र तान्छ — O(log n), table scan होइन। task-id अनुसार **Sharding/partitioning** ले 1 करोड 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 भयो) — त्यसैले काम आफैँ `task_id` मा key गरिएको idempotent हुनैपर्छ, नत्र तपाईं customer लाई दुई पटक charge गर्नुहुन्छ। Failure हरू backoff सहित retry हुन्छन्, अनि DLQ मा पुग्छन्।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले दुई कुरा probe गर्छन्: **कुशल time lookup** र **exactly-once बनाम at-least-once**। "राम्रो" भनेको table माथि cron loop; "उत्कृष्ट" भनेको sorted-set index र distributed exactly-once अव्यावहारिक छ भन्ने इमानदार स्वीकारोक्ति, त्यसैले तपाईं **at-least-once + idempotent worker** छान्नुहुन्छ। एउटा classic जाल: एउटै scheduler node मा भर पर्नु — यो SPOF र throughput सीमा हो। अर्को: task लाई second सटीकता चाहिँदा धेरै मोटो (हरेक मिनेट) poll गर्नु, वा धेरै बारीक poll गरेर store हान्नु।

## ट्रेड-अफ र failure

- **सटीकता बनाम load**: 1s tick ले second-स्तर शुद्धता दिन्छ तर बढी poll हुन्छ; scan लागत घटाउन task हरूलाई प्रति-मिनेट अनि प्रति-second sub-queue मा bucket गर्नुहोस् (Kafka र Quartz ले प्रयोग गर्ने "timing wheel" / hashed-wheel दृष्टिकोण)।
- **At-least-once बनाम exactly-once**: तपाईं crash सीमा पार गरेर साँचो exactly-once पाउन सक्नुहुन्न; idempotency key ले double execution लाई हानिरहित बनाउँछ — सही trade।
- **Failure**: poller dispatch बीचमा मर्‍यो भने, leader election ले standby promote गर्छ र un-ack task हरू redeliver हुन्छन् — केही हराउँदैन, केही दोहोरिन सक्छन्। node हरूमा **clock skew** (NTP) मा ध्यान दिनुहोस् नत्र task चाँडो/ढिलो fire हुन्छन्; र retry मा सीमा राख्नुहोस् ताकि सधैँ fail हुने task ले सधैँ loop नगरोस् — यसलाई inspection का लागि DLQ मा पठाउनुहोस्।

आर्किटेक्चर

कम्पोनेन्ट र प्रवाह

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure

सम्बन्धित प्रश्नहरू