Bagaimana Anda merancang scheduler untuk 10 juta task berjadwal?

Question

IT Interview Practice · Accepted Answer

Simpan task dalam **time-bucketed / priority queue** yang di-key berdasarkan waktu jatuh tempo, poll hanya task yang jatuh tempo *sekarang*, dan serahkan ke worker idempotent dengan pengiriman **at-least-once**. Jangan pernah men-scan 10 juta baris setiap tick — index berdasarkan fire time agar setiap poll hanya menyentuh yang 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 dan alur

- **Task store terindeks berdasarkan fire time**: sebuah Redis sorted set (`ZADD tasks score=due_ts`) atau tabel DB yang terindeks pada `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` menarik hanya task yang jatuh tempo detik ini — O(log n), bukan table scan. **Sharding/partisi** berdasarkan task-id menyebar 10 juta task ke banyak node sehingga tidak ada store tunggal yang panas.
- **Poller dengan leader election**: setiap partisi memiliki satu poller aktif yang dipilih via etcd/ZooKeeper; standby mengambil alih saat gagal. Satu leader per partisi menghindari dua poller men-dispatch task yang sama, sementara partisi menjaga throughput tetap tinggi.
- **Ready queue (Kafka)**: task yang jatuh tempo di-enqueue, memisahkan *penjadwalan* dari *eksekusi*. Worker menskala independen dari poller.
- **Worker idempotent** mengeksekusi dan **ack**. Karena pengiriman bersifat at-least-once, sebuah task bisa berjalan dua kali (poller crash setelah dispatch, sebelum menandai selesai) — jadi pekerjaannya sendiri harus idempotent, di-key pada `task_id`, atau Anda menagih pelanggan dua kali. Kegagalan di-retry dengan backoff, lalu mendarat di DLQ.

## Perspektif wawancara

Pewawancara menyelidiki dua hal: **pencarian waktu yang efisien** dan **exactly-once vs at-least-once**. "Baik" adalah loop cron atas sebuah tabel; "hebat" adalah index sorted-set ditambah pengakuan jujur bahwa exactly-once terdistribusi tidak praktis, sehingga Anda memilih **at-least-once + worker idempotent**. Jebakan klasik: mengandalkan satu node scheduler tunggal — itu SPOF dan batas throughput. Lainnya: mem-poll terlalu kasar (setiap menit) saat task butuh presisi detik, atau terlalu halus dan menggempur store.

## Trade-off dan kegagalan

- **Presisi vs beban**: tick 1 detik memberi akurasi tingkat detik tetapi lebih banyak poll; kelompokkan task ke sub-queue per-menit lalu per-detik untuk memangkas biaya scan (pendekatan "timing wheel" / hashed-wheel yang dipakai Kafka dan Quartz).
- **At-least-once vs exactly-once**: Anda tidak bisa mendapat exactly-once sejati melintasi batas crash; idempotency key membuat eksekusi ganda tidak berbahaya — trade-off yang tepat.
- **Kegagalan**: jika poller mati di tengah dispatch, leader election mempromosikan standby dan task yang belum di-ack dikirim ulang — tidak ada yang hilang, sebagian mungkin terulang. Awasi **clock skew** antar-node (NTP) atau task menyala terlalu awal/terlambat; dan batasi retry agar task yang gagal permanen tidak berputar selamanya — kirim ke DLQ untuk diperiksa.

Arsitektur

Komponen dan alur

Perspektif wawancara

Trade-off dan kegagalan

Pertanyaan terkait