System Design/04 - Cloud Design Patterns/Messaging2 min
Scheduler Agent Supervisor
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Três papéis que, juntos, garantem que um processo distribuído de vários passos chegue ao fim — ou seja desfeito de forma consistente.
| Papel | Responsabilidade |
|---|---|
| Scheduler | Orquestra os passos, mantém o estado do processo |
| Agent | Executa um passo, falando com um serviço remoto |
| Supervisor | Vigia o estado, detecta travamento e decide: repetir ou compensar |
O supervisor é a peça distintiva. Sem ele, um processo que trava — porque um agente morreu no meio — fica parado para sempre, sem que ninguém perceba.
Como funciona
O scheduler registra o estado de cada passo de forma durável. Cada passo tem um prazo. O supervisor varre periodicamente os processos e age sobre os que passaram do prazo: reexecuta se o erro parece transitório, dispara Compensating Transaction se não.
Trade-offs
É orquestração explícita, com todas as vantagens e custos que isso implica em relação a Choreography: o fluxo fica visível num lugar, a compensação é centralizada, e a auditoria é natural — ao custo de o orquestrador conhecer todos os passos e virar um componente que precisa ser mantido e escalado.
O padrão adiciona ainda a complexidade do supervisor: mais um processo rodando, mais uma política (quando repetir, quantas vezes, quando desistir), e a necessidade de que toda ação seja idempotente — o supervisor vai reexecutar passos que talvez já tenham sido concluídos, porque ele não consegue distinguir "não executou" de "executou e não registrou".
Há também o custo de latência do supervisor: ele detecta problemas por varredura periódica, então há um atraso entre o travamento e a reação.
Na prática, poucos times implementam isso do zero hoje. Step Functions, Temporal, Camunda e Cadence entregam exatamente esses três papéis como serviço — com persistência de estado, retry, timeout e visualização prontos. Reimplementar costuma ser trabalho desperdiçado.
Exemplo prático
Uma reserva de viagem: voo, hotel e carro, cada um num serviço externo.
estado: { voo: confirmado, hotel: pendente, carro: aguardando }
O agente do hotel chamou a API e morreu antes de registrar o resultado. O processo fica parado — o cliente pagou o voo e não tem hotel.
O supervisor detecta que hotel está pendente há mais de cinco minutos e age: consulta o serviço de hotel para saber se a reserva existe (por isso a chamada precisa ser idempotente, com chave de idempotência), e então prossegue ou compensa cancelando o voo.
Sem o supervisor, esse estado permaneceria até alguém reclamar — e "alguém reclamar" não é um mecanismo de recuperação.
Relacionado
Parte de Messaging · roadmap.sh/system-design