A Kestrel Workflows trocou o orquestrador externo pelo próprio Postgres para obter execução durável, usando SKIP LOCKED, chaves primárias como idempotência e um padrão de lease com sweeper.
Por que a kestrel descartou o orquestrador externo?
O caminho padrão para execução durável é um orquestrador dedicado, que persiste o workflow em data store próprio e redistribui etapas quando um worker morre.
A Kestrel recuou diante do custo: mais um sistema stateful no caminho crítico, com controles de acesso e auditoria próprios para payloads sensíveis como topologia de infraestrutura, código-fonte e logs.
Leia também
Web Summit Rio 2026 define datas e confirma palestrantes de peso no Riocentro
Como o postgres vira orquestrador na prática?
Cada gatilho, de PagerDuty a GitHub, insere uma linha em workflow_executions; o claim usa SELECT FOR UPDATE SKIP LOCKED dentro de uma transação curta que grava status e lease.
Idempotência vem da chave primária (execution_id, step_id) na tabela operation_outputs, com upsert ON CONFLICT DO NOTHING que devolve o resultado anterior em reexecuções.
Recuperação de falhas e esperas humanas
Workers renovam leases com heartbeat e um sweeper reenfileira execuções com lease expirado; sleeps e aprovações viram linhas em workflow_waits com timestamp wake_at.
Uma única instância de Postgres sustenta dezenas de milhares de workflows por segundo, segundo o artigo; PgBouncer, índices parciais e particionamento cuidam da operação.
Leia também:
Fonte: Infoq
