ਤੁਸੀਂ 1 ਕਰੋੜ timed tasks ਲਈ ਇੱਕ scheduler ਕਿਵੇਂ design ਕਰੋਗੇ?

Question

IT Interview Practice · Accepted Answer

tasks ਨੂੰ due time ਨਾਲ keyed ਇੱਕ **time-bucketed / priority queue** ਵਿੱਚ store ਕਰੋ, ਸਿਰਫ਼ *ਹੁਣ* 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`) ਜਾਂ ਇੱਕ DB table ਜੋ `(run_at)` ਉੱਤੇ indexed ਹੋਵੇ। `ZPOPMIN`/`ZRANGEBYSCORE now` ਸਿਰਫ਼ ਇਸ ਸਕਿੰਟ due tasks ਖਿੱਚਦਾ ਹੈ — O(log n), table scan ਨਹੀਂ। task-id ਨਾਲ **Sharding/partitioning** 1 ਕਰੋੜ tasks ਨੂੰ nodes ਵਿੱਚ ਫੈਲਾਉਂਦੀ ਹੈ ਤਾਂ ਜੋ ਕੋਈ single store hot ਨਾ ਹੋਵੇ।
- **leader election ਵਾਲਾ Poller**: ਹਰ partition ਦਾ ਇੱਕ active poller ਹੁੰਦਾ ਹੈ ਜੋ etcd/ZooKeeper ਰਾਹੀਂ elect ਹੁੰਦਾ ਹੈ; standbys failure ਉੱਤੇ ਲੈ ਲੈਂਦੇ ਹਨ। ਹਰ 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 ਦੋ ਵਾਰ ਚੱਲ ਸਕਦਾ ਹੈ (poller dispatch ਤੋਂ ਬਾਅਦ, done mark ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ crash ਹੋ ਗਿਆ) — ਇਸ ਲਈ ਕੰਮ ਖੁਦ idempotent ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, `task_id` ਉੱਤੇ keyed, ਨਹੀਂ ਤਾਂ ਤੁਸੀਂ ਕਿਸੇ customer ਤੋਂ double-charge ਕਰ ਬੈਠੋਗੇ। Failures 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 ਫੰਦਾ: ਇੱਕ single scheduler node ਉੱਤੇ ਭਰੋਸਾ ਕਰਨਾ — ਇਹ ਇੱਕ SPOF ਅਤੇ ਇੱਕ throughput ਛੱਤ ਹੈ। ਇੱਕ ਹੋਰ: ਬਹੁਤ coarse (ਹਰ ਮਿੰਟ) poll ਕਰਨਾ ਜਦੋਂ tasks ਨੂੰ second precision ਦੀ ਲੋੜ ਹੈ, ਜਾਂ ਬਹੁਤ fine ਅਤੇ store ਨੂੰ hammering ਕਰਨਾ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

- **Precision vs load**: 1s tick second-level 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 ਨੂੰ ਬੇਅਸਰ ਬਣਾ ਦਿੰਦੀਆਂ ਹਨ — ਸਹੀ trade।
- **Failure**: ਜੇ ਇੱਕ poller dispatch ਦੇ ਵਿਚਕਾਰ ਮਰ ਜਾਵੇ, leader election ਇੱਕ standby ਨੂੰ promote ਕਰਦੀ ਹੈ ਅਤੇ un-acked tasks redeliver ਹੁੰਦੇ ਹਨ — ਕੁਝ ਵੀ ਨਹੀਂ ਗੁਆਚਦਾ, ਕੁਝ ਦੁਹਰਾਏ ਜਾ ਸਕਦੇ ਹਨ। nodes ਦੇ ਪਾਰ **clock skew** (NTP) ਦਾ ਧਿਆਨ ਰੱਖੋ ਨਹੀਂ ਤਾਂ tasks ਜਲਦੀ/ਦੇਰੀ ਨਾਲ fire ਹੁੰਦੇ ਹਨ; ਅਤੇ retries cap ਕਰੋ ਤਾਂ ਜੋ ਇੱਕ ਹਮੇਸ਼ਾ fail ਹੋਣ ਵਾਲਾ task ਸਦਾ ਲਈ loop ਨਾ ਕਰੇ — ਇਸਨੂੰ ਜਾਂਚ ਲਈ DLQ ਵੱਲ ਭੇਜੋ।

ਆਰਕੀਟੈਕਚਰ

ਕੰਪੋਨੈਂਟ ਅਤੇ ਫਲੋ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ

ਸੰਬੰਧਿਤ ਸਵਾਲ