Come progetteresti uno scheduler per 10M di task temporizzati?

Question

IT Interview Practice · Accepted Answer

Memorizza i task in una **coda a bucket temporali / a priorità** indicizzata per orario di scadenza, esegui il polling solo dei task in scadenza *adesso* e passali a worker idempotenti con consegna **at-least-once**. Non fare mai lo scan di 10M di righe a ogni tick: indicizza per orario di attivazione così che ogni polling tocchi solo ciò che è scaduto.

## Architettura

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

## Componenti e flusso

- **Task store indicizzato per orario di attivazione**: un sorted set di Redis (`ZADD tasks score=due_ts`) o una tabella DB indicizzata su `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` estrae solo i task in scadenza in questo secondo — O(log n), non uno scan della tabella. Lo **sharding/partitioning** per task-id distribuisce i 10M di task su più nodi così che nessun singolo store sia caldo.
- **Poller con leader election**: ogni partizione ha un poller attivo eletto tramite etcd/ZooKeeper; gli standby subentrano in caso di guasto. Un solo leader per partizione evita che due poller dispaccino lo stesso task, mentre il partitioning mantiene alto il throughput.
- **Ready queue (Kafka)**: i task scaduti vengono accodati, disaccoppiando lo *scheduling* dall'*esecuzione*. I worker scalano indipendentemente dal poller.
- **Worker idempotenti** eseguono e fanno **ack**. Poiché la consegna è at-least-once, un task può girare due volte (il poller è andato in crash dopo il dispatch, prima di segnarlo come fatto): quindi il lavoro stesso deve essere idempotente, indicizzato su `task_id`, altrimenti addebiti due volte un cliente. I fallimenti ritentano con backoff, poi finiscono in una DLQ.

## Prospettiva del colloquio

L'intervistatore sonda due cose: **lookup temporale efficiente** ed **exactly-once vs at-least-once**. "Buono" è un loop cron sopra una tabella; "eccellente" è l'indice sorted-set più l'ammissione onesta che l'exactly-once distribuito è impraticabile, per cui scegli **at-least-once + worker idempotenti**. Una trappola classica: affidarsi a un unico nodo scheduler — è un SPOF e un tetto di throughput. Un'altra: fare polling troppo grossolano (ogni minuto) quando i task richiedono precisione al secondo, o troppo fine martellando lo store.

## Compromessi e modalità di guasto

- **Precisione vs carico**: un tick da 1s dà accuratezza al secondo ma più polling; raggruppa i task in sotto-code per minuto poi per secondo per ridurre il costo di scan (l'approccio "timing wheel" / hashed-wheel usato da Kafka e Quartz).
- **At-least-once vs exactly-once**: non puoi ottenere un vero exactly-once attraverso un confine di crash; le idempotency key rendono innocua la doppia esecuzione — il compromesso giusto.
- **Guasto**: se un poller muore a metà dispatch, la leader election promuove uno standby e i task non ancora ack vengono riconsegnati — nulla va perso, alcuni possono ripetersi. Attenzione al **clock skew** tra i nodi (NTP) o i task si attivano in anticipo/ritardo; e limita i retry così che un task in fallimento permanente non giri all'infinito — mandalo alla DLQ per ispezione.

Architettura

Componenti e flusso

Prospettiva del colloquio

Compromessi e modalità di guasto

Domande correlate