Cum ai proiecta un scheduler pentru 10M de task-uri programate?

Question

IT Interview Practice · Accepted Answer

Stochează task-urile într-o **coadă cu bucket-uri de timp / prioritate** cheiată după momentul scadenței, poll-uiește doar task-urile scadente *acum* și predă-le unor workeri idempotenți cu livrare **at-least-once**. Nu scana niciodată 10M de rânduri la fiecare tick — indexează după momentul declanșării, astfel încât fiecare poll să atingă doar ce este scadent.

## Arhitectură

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

## Componente și flux

- **Task store indexat după momentul declanșării**: un sorted set Redis (`ZADD tasks score=due_ts`) sau o tabelă DB indexată pe `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` extrage doar task-urile scadente în secunda aceasta — O(log n), nu un table scan. **Sharding-ul/partiționarea** după task-id distribuie 10M de task-uri pe noduri, astfel încât niciun store să nu fie fierbinte.
- **Poller cu leader election**: fiecare partiție are un poller activ ales prin etcd/ZooKeeper; standby-urile preiau la eșec. Un singur leader per partiție evită ca doi polleri să distribuie același task, în timp ce partiționarea menține throughput-ul ridicat.
- **Ready queue (Kafka)**: task-urile scadente sunt puse în coadă, decuplând *planificarea* de *execuție*. Workerii scalează independent de poller.
- **Workeri idempotenți** execută și fac **ack**. Deoarece livrarea este at-least-once, un task poate rula de două ori (poller-ul a căzut după distribuire, înainte de a-l marca ca finalizat) — deci munca în sine trebuie să fie idempotentă, cheiată pe `task_id`, altfel taxezi un client de două ori. Eșecurile reîncearcă cu backoff, apoi ajung într-un DLQ.

## Perspectiva de interviu

Intervievatorul sondează două lucruri: **căutarea eficientă după timp** și **exactly-once vs at-least-once**. "Bine" este un cron loop peste o tabelă; "excelent" este indexul cu sorted set plus recunoașterea onestă că exactly-once distribuit este impracticabil, deci alegi **at-least-once + workeri idempotenți**. O capcană clasică: să te bazezi pe un singur nod de scheduler — este un SPOF și un plafon de throughput. Alta: să poll-uiești prea grosier (la fiecare minut) când task-urile au nevoie de precizie de secundă, sau prea fin, bombardând store-ul.

## Compromisuri și eșecuri

- **Precizie vs încărcare**: un tick de 1s oferă acuratețe la nivel de secundă, dar mai multe poll-uri; grupează task-urile în sub-cozi per minut apoi per secundă pentru a reduce costul scanării (abordarea "timing wheel" / hashed-wheel folosită de Kafka și Quartz).
- **At-least-once vs exactly-once**: nu poți obține exactly-once real peste o graniță de crash; cheile de idempotență fac dubla execuție inofensivă — compromisul corect.
- **Eșec**: dacă un poller moare în mijlocul distribuirii, leader election-ul promovează un standby, iar task-urile ne-ack-uite se redistribuie — nimic nu se pierde, unele se pot repeta. Fii atent la **clock skew** între noduri (NTP), altfel task-urile se declanșează prea devreme/târziu; și plafonează reîncercările, astfel încât un task care eșuează permanent să nu bucleze la nesfârșit — trimite-l în DLQ pentru inspecție.

Arhitectură

Componente și flux

Perspectiva de interviu

Compromisuri și eșecuri

Întrebări conexe