Comment concevriez-vous un scheduler pour 10M de tâches planifiées ?

Question

IT Interview Practice · Accepted Answer

Stockez les tâches dans une **queue à buckets temporels / à priorité** indexée par heure d'échéance, ne pollez que les tâches dues *maintenant*, et confiez-les à des workers idempotents avec une livraison **at-least-once**. Ne scannez jamais 10M de lignes à chaque tick — indexez par heure de déclenchement pour que chaque poll ne touche que ce qui est dû.

## Architecture

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

## Composants et flux

- **Task store indexé par heure de déclenchement** : un sorted set Redis (`ZADD tasks score=due_ts`) ou une table DB indexée sur `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` ne tire que les tâches dues cette seconde — O(log n), pas un table scan. Le **sharding/partitionnement** par task-id répartit les 10M de tâches sur plusieurs nœuds pour qu'aucun store ne soit chaud.
- **Poller avec leader election** : chaque partition a un poller actif élu via etcd/ZooKeeper ; les standbys prennent le relais en cas de panne. Un leader par partition évite que deux pollers dispatchent la même tâche, tandis que le partitionnement maintient un throughput élevé.
- **Ready queue (Kafka)** : les tâches dues sont enfilées, découplant le *scheduling* de l'*exécution*. Les workers scalent indépendamment du poller.
- **Workers idempotents** exécutent et **ack**. Comme la livraison est at-least-once, une tâche peut s'exécuter deux fois (poller crashé après le dispatch, avant de marquer terminé) — donc le travail lui-même doit être idempotent, indexé sur `task_id`, sinon vous facturez deux fois un client. Les échecs réessaient avec backoff, puis atterrissent dans une DLQ.

## Perspective d'entretien

L'examinateur sonde deux choses : la **recherche temporelle efficace** et l'**exactly-once vs at-least-once**. « Bien » c'est une boucle cron sur une table ; « excellent » c'est l'index sorted-set plus l'aveu honnête que l'exactly-once distribué est impraticable, donc vous choisissez **at-least-once + workers idempotents**. Un piège classique : se reposer sur un seul nœud scheduler — c'est un SPOF et un plafond de throughput. Un autre : poller trop grossièrement (chaque minute) quand les tâches ont besoin d'une précision à la seconde, ou trop finement et marteler le store.

## Compromis et pannes

- **Précision vs charge** : un tick de 1s donne une précision à la seconde mais plus de polls ; bucketisez les tâches en sous-queues par minute puis par seconde pour réduire le coût de scan (l'approche « timing wheel » / hashed-wheel utilisée par Kafka et Quartz).
- **At-least-once vs exactly-once** : vous ne pouvez pas obtenir un vrai exactly-once à travers une frontière de crash ; les clés d'idempotence rendent la double exécution inoffensive — le bon compromis.
- **Panne** : si un poller meurt en plein dispatch, la leader election promeut un standby et les tâches non-ack sont redélivrées — rien n'est perdu, certaines peuvent se répéter. Surveillez le **clock skew** entre les nœuds (NTP) sinon les tâches se déclenchent en avance/retard ; et plafonnez les réessais pour qu'une tâche en échec permanent ne boucle pas indéfiniment — envoyez-la à la DLQ pour inspection.

Architecture

Composants et flux

Perspective d'entretien

Compromis et pannes

Questions connexes