Ungeundaje scheduler kwa tasks milioni 10 zenye muda?

Question

IT Interview Practice · Accepted Answer

Hifadhi tasks katika **time-bucketed / priority queue** iliyowekwa index kwa due time, poll tasks zinazostahili *sasa* tu, na uzikabidhi kwa workers za idempotent kwa **at-least-once** delivery. Kamwe usiskan rows milioni 10 kila tick — weka index kwa fire time ili kila poll iguse kile kinachostahili tu.

## Usanifu

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

## Vipengele na mtiririko

- **Task store yenye index ya fire time**: sorted set ya Redis (`ZADD tasks score=due_ts`) au jedwali la DB lenye index kwenye `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` huvuta tasks zinazostahili sekunde hii tu — O(log n), si table scan. **Sharding/partitioning** kwa task-id husambaza tasks milioni 10 kwenye nodes ili hakuna store moja iwe moto.
- **Poller yenye leader election**: kila partition ina poller moja hai iliyochaguliwa kupitia etcd/ZooKeeper; standbys huchukua nafasi kwenye kushindwa. Leader mmoja kwa kila partition huepusha pollers mbili kudispatch task ile ile, huku partitioning ikidumisha throughput ya juu.
- **Ready queue (Kafka)**: tasks zinazostahili huwekwa kwenye foleni, zikitenganisha *scheduling* na *execution*. Workers hupanuka kwa kujitegemea na poller.
- **Idempotent workers** hutekeleza na **ack**. Kwa sababu delivery ni at-least-once, task inaweza kuendeshwa mara mbili (poller ilianguka baada ya dispatch, kabla ya kuiweka kama imekamilika) — hivyo kazi yenyewe lazima iwe idempotent, iliyowekwa key kwa `task_id`, la sivyo unamtoza mteja mara mbili. Kushindwa hujaribiwa tena kwa backoff, kisha huingia DLQ.

## Mtazamo wa mahojiano

Mhojiwa huchunguza mambo mawili: **utafutaji bora wa muda** na **exactly-once vs at-least-once**. "Nzuri" ni cron loop juu ya jedwali; "bora sana" ni index ya sorted-set pamoja na kukiri kwa uwazi kuwa distributed exactly-once haiwezekani kivitendo, hivyo unachagua **at-least-once + idempotent workers**. Mtego wa kawaida: kutegemea scheduler node moja — ni SPOF na dari ya throughput. Mwingine: kupoll kwa ukubwa mno (kila dakika) wakati tasks zinahitaji usahihi wa sekunde, au kwa udogo mno na kupiga store kupita kiasi.

## Maelewano na hitilafu

- **Precision vs load**: tick ya 1s hutoa usahihi wa kiwango cha sekunde lakini polls zaidi; weka tasks katika buckets za kila dakika kisha sub-queues za kila sekunde ili kupunguza gharama ya scan (mbinu ya "timing wheel" / hashed-wheel inayotumiwa na Kafka na Quartz).
- **At-least-once vs exactly-once**: huwezi kupata exactly-once halisi kuvuka mpaka wa crash; idempotency keys hufanya utekelezaji wa mara mbili usidhuru — maelewano sahihi.
- **Hitilafu**: poller ikifa katikati ya dispatch, leader election hupandisha standby na tasks zisizo-ack hutumwa tena — hakuna kinachopotea, baadhi zinaweza kurudiwa. Angalia **clock skew** kwenye nodes (NTP) la sivyo tasks huwaka mapema/kuchelewa; na weka kikomo cha retries ili task inayoshindwa daima isizunguke milele — ipeleke DLQ kwa ukaguzi.

Usanifu

Vipengele na mtiririko

Mtazamo wa mahojiano

Maelewano na hitilafu

Maswali yanayohusiana