Como transformar o Postgres em orquestrador de workflows duráveis sem Temporal

INSERT INTO operation_outputs (execution_id, step_id, output)
VALUES ($1, $2, $3)
ON CONFLICT (execution_id, step_id) DO NOTHING
RETURNING output;

Se um worker em recuperação re-executa um step que já commitou, a constraint de unicidade impede o checkpoint duplicado. Em vez de rodar o efeito colateral de novo, o worker lê o checkpoint existente e devolve o resultado anterior. É o banco, e não o código da aplicação, garantindo idempotência. É um exemplo bonito de expressar um invariante de sistema distribuído como constraint relacional em vez de escrever a contabilidade na mão.

Recovery com lease e sweeper

A falha interessante é quando um worker reivindica uma execução, coloca em running e morre (OOM kill, drain de nó, eviction de pod). A linha fica presa em running sem dono vivo. A solução são as colunas de lease: o worker que possui uma execução dá heartbeat num intervalo, empurrando lease_expires para frente. Um sweeper periódico devolve para a fila tudo que expirou:

UPDATE workflow_executions
SET status = 'enqueued', owner_id = NULL
WHERE status = 'running'
AND lease_expires < now();

A duração do lease é um tradeoff explícito: curto demais e um worker lento (mas vivo) tem o trabalho roubado; longo demais e o recovery após crash atrasa. Aqui a idempotência dos checkpoints é o que dá liberdade para usar leases agressivos, porque um sweep falso-positivo causaria no máximo trabalho duplicado, não efeito colateral em dobro.

Sleeps e aprovações humanas que sobrevivem a restart

Esperar aprovação humana no Slack, que pode levar de duas horas a duas semanas, também é durável. Em vez de uma goroutine rezando para o pod viver o suficiente, é só uma linha numa tabela workflow_waits com um timestamp wake_at. A execução se coloca em waiting, e um sweeper re-enfileira o que já venceu. Não importa o tamanho da janela de espera: o custo é sempre o mesmo, uma linha.

Observabilidade e escala: onde a conta fecha

Como cada workflow e cada step é uma linha, monitoramento vira SQL puro. Quer todas as execuções que deram erro no mês? SELECT * FROM workflow_executions WHERE created_at > NOW() - INTERVAL '1 month' AND status = 'error'. Dá para ir além e cruzar execuções com steps e aprovações para responder "quais fixes foram rejeitados e em qual step?". Com orquestradores externos, esse tipo de query relacional exige exportar o estado do key-value para um sistema de analytics separado.

Sobre escala, o autor afirma que uma única instância aguentou dezenas de milhares de workflows por segundo sem read replicas nem Citus, escalando throughput com workers stateless. E cita os pontos de atenção reais: pressão de conexão (a recomendação é PgBouncer em transaction pooling na frente, com backoff e jitter no polling) e dead tuples/bloat em tabela de fila de alto churn (tuning de autovacuum, índices parciais e particionamento das execuções concluídas para longe da fila viva).

O próprio artigo é honesto sobre o limite: se você precisa de fan-out para milhares de workers e latência de dispatch sub-milissegundo, um Temporal ainda é a escolha arquitetural melhor. O Kestrel roda pipelines de automação I/O-bound, que duram de segundos a horas e precisam de concorrência modesta, e para esse perfil o Postgres não é concessão, é encaixe.

O que muda para quem constrói no Brasil

Para startup e time pequeno, o recado prático é que uma capacidade que muita gente presume exigir um serviço externo pode sair de um banco que você já opera, paga e sabe manter. Menos um sistema stateful no caminho crítico significa menos infra para provisionar, menos superfície de auditoria (LGPD↳LGPD14 conteúdosComo utilizar a LGPD com o objetivo de conformidade e inovação?Gestão Dev & TI · out 2021LGPD coloca pressão inédita nos responsáveis pela tecnologia das empresasData · ago 2021Proteção de dados: LGPD é sancionada e começa a valerData · set 2020Ver tudo em Gestão Dev & TI → agradece: nenhum payload de workflow sai do banco) e uma conta de nuvem que não ganha mais um componente. Confiabilidade e segurança colapsam numa dependência só, porque, se o Postgres cair, o resto do produto já caiu junto.

O ponto de partida honesto antes de replicar o padrão: avalie o perfil da sua carga. Se seus workflows são de automação I/O-bound com concorrência moderada, o desenho descrito é reproduzível hoje com SKIP LOCKED, constraints e um sweeper. Se você precisa de ordenação estrita, fan-out massivo ou dispatch sub-milissegundo, os próprios autores apontam a saída para o orquestrador dedicado.

Fonte: InfoQ