Kif tiddisinja scheduler għal 10M task bil-ħin?

Question

IT Interview Practice · Accepted Answer

Aħżen it-tasks f'**time-bucketed / priority queue** ibbażata fuq il-ħin dovut, agħmel poll biss tat-tasks dovuti *issa*, u għaddihom lil workers idempotenti b'delivery **at-least-once**. Qatt m'għandek tagħmel scan ta' 10M row kull tick — indexja skont il-fire time biex kull poll imiss biss dak li huwa dovut.

## Arkitettura

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

## Komponenti u fluss

- **Task store indexjat skont il-fire time**: Redis sorted set (`ZADD tasks score=due_ts`) jew DB table indexjat fuq `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` jiġbdu biss it-tasks dovuti f'din is-sekonda — O(log n), mhux table scan. **Sharding/partitioning** skont task-id jifrex l-10M task fuq nodes biex ebda store ma jkun jaħraq.
- **Poller b'leader election**: kull partition għandu poller attiv wieħed elett permezz ta' etcd/ZooKeeper; l-istandbys jieħdu post fuq falliment. Leader wieħed għal kull partition jevita żewġ pollers jiddispaċċjaw l-istess task, filwaqt li l-partitioning iżomm it-throughput għoli.
- **Ready queue (Kafka)**: it-tasks dovuti jiddaħħlu fil-queue, u jiddekjaw l-*iskedar* mill-*eżekuzzjoni*. Il-workers jiskalaw indipendentement mill-poller.
- **Idempotent workers** jeżegwixxu u jagħmlu **ack**. Peress li d-delivery huwa at-least-once, task jista' jaħdem darbtejn (il-poller waqa' wara d-dispatch, qabel ma mmarkah lest) — allura x-xogħol innifsu jrid ikun idempotenti, ibbażat fuq `task_id`, inkella tiċċarġja klijent darbtejn. Il-fallimenti jerġgħu jippruvaw b'backoff, imbagħad jinżlu f'DLQ.

## Perspettiva tal-intervista

L-intervistatur jgħarbel żewġ affarijiet: **time lookup effiċjenti** u **exactly-once vs at-least-once**. "Tajjeb" huwa cron loop fuq table; "eċċellenti" huwa l-index tas-sorted set flimkien mal-ammissjoni onesta li exactly-once distribwit huwa imprattiku, allura tagħżel **at-least-once + idempotent workers**. Nassa klassika: li toqgħod fuq scheduler node wieħed — huwa SPOF u saqaf ta' throughput. Oħra: li tagħmel poll b'mod krud (kull minuta) meta t-tasks jeħtieġu preċiżjoni ta' sekonda, jew wisq spiss u tħabbat il-store.

## Trade-offs u fallimenti

- **Preċiżjoni vs load**: tick ta' 1s jagħti preċiżjoni fil-livell tas-sekonda imma aktar polls; ibbakketja t-tasks f'sub-queues għal kull minuta imbagħad għal kull sekonda biex tnaqqas il-kost tal-iscan (l-approċċ "timing wheel" / hashed-wheel użat minn Kafka u Quartz).
- **At-least-once vs exactly-once**: ma tistax tikseb exactly-once veru minn crash boundary; idempotency keys jagħmlu eżekuzzjoni doppja bla ħsara — it-trade tajjeb.
- **Fallimenti**: jekk poller imut f'nofs dispatch, il-leader election tippromwovi standby u tasks mhux acked jerġgħu jiġu mibgħuta — xejn ma jintilef, xi wħud jistgħu jirrepetu. Oqgħod attent għal **clock skew** fuq in-nodes (NTP) inkella t-tasks jiskattaw kmieni/tard; u llimita r-retries biex task li jfalli b'mod permanenti ma jkomplix loop għal dejjem — ibgħatu lejn id-DLQ għal spezzjoni.

Arkitettura

Komponenti u fluss

Perspettiva tal-intervista

Trade-offs u fallimenti

Mistoqsijiet relatati