Como você projetaria um scheduler para 10M de tarefas agendadas?

Question

IT Interview Practice · Accepted Answer

Armazene as tarefas em uma **fila de prioridade / dividida em buckets de tempo** indexada pelo horário de vencimento, faça poll apenas das tarefas vencidas *agora* e as entregue a workers idempotentes com entrega **at-least-once**. Nunca escaneie 10M de linhas a cada tick — indexe pelo horário de disparo para que cada poll toque apenas o que está vencido.

## Arquitetura

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

- **Task store indexado pelo horário de disparo**: um sorted set do Redis (`ZADD tasks score=due_ts`) ou uma tabela do DB indexada em `(run_at)`. `ZPOPMIN`/`ZRANGEBYSCORE now` puxa apenas as tarefas vencidas neste segundo — O(log n), não um table scan. **Sharding/particionamento** por task-id espalha 10M de tarefas por vários nós para que nenhum store único fique quente.
- **Poller com eleição de líder**: cada partição tem um poller ativo eleito via etcd/ZooKeeper; standbys assumem em caso de falha. Um líder por partição evita que dois pollers despachem a mesma tarefa, enquanto o particionamento mantém o throughput alto.
- **Fila de prontos (Kafka)**: tarefas vencidas são enfileiradas, desacoplando *agendamento* de *execução*. Os workers escalam independentemente do poller.
- **Workers idempotentes** executam e dão **ack**. Como a entrega é at-least-once, uma tarefa pode rodar duas vezes (o poller caiu após o despacho, antes de marcar como concluída) — então o próprio trabalho deve ser idempotente, indexado por `task_id`, ou você cobra um cliente em duplicidade. Falhas fazem retry com backoff e depois caem em uma DLQ.

## Perspectiva de entrevista

O entrevistador sonda duas coisas: **busca eficiente por tempo** e **exactly-once vs at-least-once**. "Bom" é um loop cron sobre uma tabela; "excelente" é o índice de sorted-set mais a admissão honesta de que exactly-once distribuído é impraticável, então você escolhe **at-least-once + workers idempotentes**. Uma armadilha clássica: depender de um único nó scheduler — é um SPOF e um teto de throughput. Outra: fazer poll de forma grosseira demais (a cada minuto) quando as tarefas precisam de precisão de segundo, ou fina demais e martelar o store.

## Trade-offs e falhas

- **Precisão vs carga**: um tick de 1s dá precisão de segundo mas mais polls; agrupe tarefas em sub-filas por minuto e depois por segundo para cortar o custo de scan (a abordagem "timing wheel" / hashed-wheel usada por Kafka e Quartz).
- **At-least-once vs exactly-once**: você não consegue exactly-once verdadeiro através de uma fronteira de crash; chaves de idempotência tornam a execução dupla inofensiva — o trade-off certo.
- **Falha**: se um poller morrer no meio do despacho, a eleição de líder promove um standby e tarefas sem ack são reentregues — nada é perdido, algumas podem se repetir. Fique atento a **clock skew** entre nós (NTP) ou tarefas disparam cedo/tarde; e limite os retries para que uma tarefa permanentemente falha não fique em loop para sempre — envie-a para a DLQ para inspeção.

Arquitetura

Componentes e fluxo

Perspectiva de entrevista

Trade-offs e falhas

Perguntas relacionadas