Kako biste dizajnirali scheduler za 10 milijuna vremenski zakazanih zadataka?

Question

IT Interview Practice · Accepted Answer

Pohranite zadatke u **vremenski segmentiran / prioritetni queue** ključan po vremenu dospijeća, pollajte samo zadatke koji dospijevaju *sada* i predajte ih idempotentnim workerima uz **at-least-once** isporuku. Nikada ne skenirajte 10 milijuna redaka svaki tick — indeksirajte po vremenu okidanja da svaki poll dotakne samo ono što dospijeva.

## Arhitektura

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

## Komponente i tok

- **Task store indeksiran po vremenu okidanja**: Redis sorted set (`ZADD tasks score=due_ts`) ili DB tablica indeksirana na `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` povlači samo zadatke koji dospijevaju ove sekunde — O(log n), a ne skeniranje tablice. **Sharding/particioniranje** po task-id-u širi 10 milijuna zadataka preko čvorova tako da nijedan pojedini store nije vruć.
- **Poller s leader electionom**: svaka particija ima jedan aktivni poller izabran preko etcd/ZooKeeper; standbyji preuzimaju pri neuspjehu. Jedan leader po particiji izbjegava da dva pollera otpreme isti zadatak, dok particioniranje održava visok throughput.
- **Ready queue (Kafka)**: dospjeli zadaci stavljaju se u queue, razdvajajući *zakazivanje* od *izvršavanja*. Workeri skaliraju neovisno o polleru.
- **Idempotentni workeri** izvršavaju i **ackaju**. Budući da je isporuka at-least-once, zadatak se može izvršiti dvaput (poller se srušio nakon otpreme, prije označavanja gotovim) — pa sam posao mora biti idempotentan, ključan na `task_id`, inače dvaput naplatite kupca. Neuspjesi se ponavljaju s backoffom, zatim završavaju u DLQ-u.

## Perspektiva intervjua

Ispitivač ispituje dvije stvari: **efikasno vremensko traženje** i **exactly-once vs at-least-once**. "Dobro" je cron petlja preko tablice; "odlično" je sorted-set indeks plus iskreno priznanje da je distribuirani exactly-once nepraktičan, pa birate **at-least-once + idempotentne workere**. Klasična zamka: oslanjanje na jedan scheduler čvor — to je SPOF i strop throughputa. Druga: prerijetko pollanje (svake minute) kad zadaci trebaju sekundnu preciznost, ili prečesto uz zatrpavanje storea.

## Kompromisi i neuspjesi

- **Preciznost vs opterećenje**: 1 s tick daje sekundnu točnost ali više pollova; segmentirajte zadatke u per-minutne pa per-sekundne pod-queue kako biste smanjili trošak skeniranja ("timing wheel" / hashed-wheel pristup koji koriste Kafka i Quartz).
- **At-least-once vs exactly-once**: pravi exactly-once ne možete dobiti preko granice pada; idempotentni ključevi čine dvostruko izvršavanje bezopasnim — ispravan kompromis.
- **Neuspjeh**: ako poller padne usred otpreme, leader election promovira standby i neackani zadaci se ponovno isporučuju — ništa se ne gubi, neki se mogu ponoviti. Pazite na **clock skew** preko čvorova (NTP) ili zadaci okidaju prerano/prekasno; i ograničite retryje kako trajno neuspješan zadatak ne bi zauvijek kružio — pošaljite ga u DLQ na pregled.

Arhitektura

Komponente i tok

Perspektiva intervjua

Kompromisi i neuspjesi

Povezana pitanja