Kepiye sampeyan bakal ngrancang scheduler kanggo 10 yuta tugas kanthi wektu tartamtu?

Question

IT Interview Practice · Accepted Answer

Simpen tugas ing **time-bucketed / priority queue** sing dikunci miturut wektu jatuh tempo, poll mung tugas sing jatuh tempo *saiki*, lan wenehke menyang worker idempotent kanthi pangiriman **at-least-once**. Aja tau nge-scan 10 yuta row saben tik — indeks miturut wektu fire supaya saben poll mung ndemek apa sing wis jatuh tempo.

## Arsitektur

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

## Komponen lan aliran

- **Task store diindeks miturut wektu fire**: Redis sorted set (`ZADD tasks score=due_ts`) utawa tabel DB sing diindeks ing `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` narik mung tugas sing jatuh tempo ing detik iki — O(log n), dudu scan tabel. **Sharding/partisi** miturut task-id nyebar 10 yuta tugas ing pirang-pirang node supaya ora ana siji store sing panas.
- **Poller kanthi leader election**: saben partisi duwe siji poller aktif sing dipilih liwat etcd/ZooKeeper; standby njupuk alih nalika gagal. Siji leader saben partisi nyegah loro poller ngirim tugas sing padha, dene partisi njaga throughput tetep dhuwur.
- **Ready queue (Kafka)**: tugas sing jatuh tempo dilebokake antrian, misahake *scheduling* saka *eksekusi*. Worker skala kanthi mandiri saka poller.
- **Worker idempotent** nglakokake lan **ack**. Amarga pangiriman iku at-least-once, sawijining tugas bisa mlaku kaping pindho (poller crash sawise ngirim, sadurunge menehi tandha rampung) — mula gaweane dhewe kudu idempotent, dikunci miturut `task_id`, yen ora sampeyan bakal ngecas pelanggan kaping pindho. Kegagalan dicoba maneh nganggo backoff, banjur mlebu DLQ.

## Sudut pandang wawancara

Pewawancara nyoba loro perkara: **panelusuran wektu sing efisien** lan **exactly-once vs at-least-once**. "Apik" yaiku loop cron marang tabel; "apik banget" yaiku indeks sorted-set ditambah pengakuan jujur yen exactly-once terdistribusi ora praktis, mula sampeyan milih **at-least-once + worker idempotent**. Jebakan klasik: gumantung ing siji node scheduler — iku SPOF lan plafon throughput. Liyane: nge-poll kekasaren (saben menit) nalika tugas mbutuhake presisi detik, utawa kealusen banjur nggebuk store.

## Trade-off lan kegagalan

- **Presisi vs beban**: tik 1 detik menehi akurasi level detik nanging luwih akeh poll; bucketing tugas dadi sub-queue saben menit banjur saben detik kanggo ngurangi biaya scan (pendekatan "timing wheel" / hashed-wheel sing dipigunakake Kafka lan Quartz).
- **At-least-once vs exactly-once**: sampeyan ora bisa entuk exactly-once tenanan ngliwati wates crash; idempotency key ndadekake eksekusi kaping pindho ora mbebayani — trade sing bener.
- **Kegagalan**: yen poller mati ing tengah pangiriman, leader election mpromosekake standby lan tugas sing durung di-ack dikirim maneh — ora ana sing ilang, sawetara bisa mbaleni. Awasi **clock skew** ing antarane node (NTP) utawa tugas fire kegasik/kasep; lan wates retry supaya tugas sing gagal permanen ora looping salawase — kirim menyang DLQ kanggo dipriksa.

Arsitektur

Komponen lan aliran

Sudut pandang wawancara

Trade-off lan kegagalan

Pitakon sing gegandhengan