¿Cómo diseñarías un scheduler para 10M de tareas programadas?

Question

IT Interview Practice · Accepted Answer

Almacena las tareas en una **cola con buckets temporales / de prioridad** indexada por hora de vencimiento, sondea solo las tareas que vencen *ahora*, y entrégalas a workers idempotentes con entrega **at-least-once**. Nunca escanees 10M de filas en cada tick — indexa por hora de disparo para que cada poll toque solo lo que vence.

## Arquitectura

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

## Componentes y flujo

- **Task store indexado por hora de disparo**: un sorted set de Redis (`ZADD tasks score=due_ts`) o una tabla de DB indexada en `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` extrae solo las tareas que vencen este segundo — O(log n), no un table scan. El **sharding/particionado** por task-id reparte los 10M de tareas entre nodos para que ningún store individual esté caliente.
- **Poller con leader election**: cada partición tiene un poller activo elegido vía etcd/ZooKeeper; los standbys toman el relevo ante un fallo. Un líder por partición evita que dos pollers despachen la misma tarea, mientras que el particionado mantiene alto el throughput.
- **Ready queue (Kafka)**: las tareas vencidas se encolan, desacoplando la *programación* de la *ejecución*. Los workers escalan independientemente del poller.
- **Workers idempotentes** ejecutan y hacen **ack**. Como la entrega es at-least-once, una tarea puede correr dos veces (el poller se cayó tras despachar, antes de marcarla como hecha) — así que el trabajo en sí debe ser idempotente, con clave en `task_id`, o le cobrarás dos veces a un cliente. Los fallos reintentan con backoff y luego aterrizan en una DLQ.

## Perspectiva de la entrevista

El entrevistador sondea dos cosas: la **búsqueda temporal eficiente** y **exactly-once vs at-least-once**. "Bueno" es un bucle de cron sobre una tabla; "excelente" es el índice de sorted-set más la admisión honesta de que el exactly-once distribuido es impracticable, así que eliges **at-least-once + workers idempotentes**. Una trampa clásica: depender de un único nodo scheduler — es un SPOF y un techo de throughput. Otra: sondear con demasiada granularidad gruesa (cada minuto) cuando las tareas necesitan precisión de segundos, o demasiado fina y martillear el store.

## Compensaciones y fallos

- **Precisión vs carga**: un tick de 1s da precisión a nivel de segundo pero más polls; agrupa las tareas en subcolas por minuto y luego por segundo para reducir el coste de escaneo (el enfoque "timing wheel" / hashed-wheel usado por Kafka y Quartz).
- **At-least-once vs exactly-once**: no puedes obtener verdadero exactly-once a través de una frontera de crash; las idempotency keys hacen inofensiva la doble ejecución — la compensación correcta.
- **Fallo**: si un poller muere a mitad de despacho, la leader election promueve un standby y las tareas sin ack se reentregan — nada se pierde, algunas pueden repetirse. Vigila el **clock skew** entre nodos (NTP) o las tareas dispararán antes/después; y limita los reintentos para que una tarea que falla permanentemente no haga bucle para siempre — envíala a la DLQ para inspección.

Arquitectura

Componentes y flujo

Perspectiva de la entrevista

Compensaciones y fallos

Preguntas relacionadas