Introdução ao padrão process manager para orquestração de longos fluxos

1. Fundamentos do Process Manager

No universo dos sistemas distribuídos, o padrão Process Manager surge como uma solução arquitetural para coordenar fluxos de trabalho que atravessam múltiplos serviços. Diferente da coreografia — onde cada serviço reage a eventos sem um coordenador central —, a orquestração com Process Manager estabelece um ponto centralizado que define, monitora e controla cada etapa do fluxo.

O Process Manager atua como um coordenador inteligente: ele recebe eventos, toma decisões baseadas no estado atual do fluxo e emite comandos para serviços específicos. Sua principal característica é gerenciar fluxos de longa duração, que podem levar minutos, horas ou até dias para serem concluídos.

A distinção entre coreografia e orquestração é crucial:
- Coreografia: serviços trocam eventos diretamente, sem controle central. Ideal para fluxos simples e independentes.
- Orquestração: um Process Manager centraliza a lógica do fluxo. Necessário quando há dependências complexas entre etapas.

2. Problemas que o Process Manager Resolve

Gerenciamento de Estados Complexos

Em fluxos multi-serviço, cada serviço mantém seu próprio estado. O Process Manager mantém o estado global do fluxo, permitindo saber exatamente em que etapa o processo se encontra.

Tratamento de Falhas Parciais

Falhas em sistemas distribuídos são inevitáveis. O Process Manager implementa estratégias de compensação: se o pagamento falha após o estoque ser reservado, ele dispara comandos para liberar a reserva.

Consistência Eventual

Operações assíncronas exigem consistência eventual. O Process Manager garante que, mesmo com atrasos, o fluxo complete todas as etapas ou reverta completamente.

3. Estrutura Interna de um Process Manager

Máquina de Estados

Cada instância do Process Manager é uma máquina de estados. Estados representam etapas do fluxo, e eventos disparam transições.

Estado: PEDIDO_CRIADO
  Evento: PAGAMENTO_APROVADO -> Estado: PAGAMENTO_CONFIRMADO
  Evento: PAGAMENTO_RECUSADO -> Estado: PAGAMENTO_FALHOU

Estado: PAGAMENTO_CONFIRMADO
  Evento: ESTOQUE_RESERVADO -> Estado: RESERVA_CONFIRMADA
  Evento: ESTOQUE_INDISPONIVEL -> Estado: RESERVA_FALHOU

Armazenamento de Estado

Para resiliência, o estado deve ser persistido. Bases de dados como PostgreSQL ou bancos otimizados para eventos são comuns.

CREATE TABLE process_manager_state (
    process_id UUID PRIMARY KEY,
    current_state VARCHAR(50),
    payload JSONB,
    created_at TIMESTAMP,
    updated_at TIMESTAMP
);

Timeouts e Compensações

Fluxos podem travar. Timeouts disparam ações de compensação:

Timeout de 5 minutos no estado AGUARDANDO_PAGAMENTO
Ação: notificar usuário + cancelar pedido

4. Implementação Prática com Exemplos

Vamos modelar um fluxo de pedido completo: criação, pagamento, reserva de estoque e entrega.

Estrutura do Process Manager

ProcessManager:
  process_id: "order-12345"
  current_state: "CREATED"
  data: {
    order_id: "ORD-001",
    customer_id: "CUST-456",
    items: ["SKU-001", "SKU-002"],
    total_amount: 250.00
  }
  timers: []

Recebendo Eventos e Emitindo Comandos

Evento recebido: OrderCreated
  Ação: Mudar estado para AWAITING_PAYMENT
  Comando emitido: ProcessPayment(order_id, amount)

Evento recebido: PaymentApproved
  Ação: Mudar estado para PAYMENT_CONFIRMED
  Comando emitido: ReserveStock(order_id, items)

Evento recebido: PaymentFailed
  Ação: Mudar estado para PAYMENT_FAILED
  Comando emitido: CancelOrder(order_id, reason)

Evento recebido: StockReserved
  Ação: Mudar estado para STOCK_RESERVED
  Comando emitido: ScheduleDelivery(order_id, address)

Tratamento de Falhas

Timeout no estado AWAITING_PAYMENT (5 minutos):
  Ação: Mudar estado para PAYMENT_TIMEOUT
  Comando emitido: CancelOrder(order_id, "Payment timeout")

Falha na reserva de estoque:
  Ação: Mudar estado para STOCK_FAILED
  Comando emitido: RefundPayment(order_id)
  Comando emitido: CancelOrder(order_id, "Out of stock")

Exemplo de Persistência do Fluxo

INSERT INTO process_manager_state VALUES (
  'order-12345',
  'AWAITING_PAYMENT',
  '{"order_id": "ORD-001", "total": 250.00}',
  NOW(),
  NOW()
);

5. Integração com Padrões Complementares

Sagas para Compensação

O Process Manager implementa o padrão Saga: cada etapa possui uma ação compensatória. Se uma etapa falha, todas as anteriores são revertidas.

Etapas do Saga:
  1. Criar Pedido (compensação: Cancelar Pedido)
  2. Processar Pagamento (compensação: Reembolsar)
  3. Reservar Estoque (compensação: Liberar Estoque)
  4. Agendar Entrega (compensação: Cancelar Agendamento)

Event Sourcing

Combinar Process Manager com Event Sourcing permite rastrear cada evento que alterou o estado do fluxo, garantindo auditoria completa.

CQRS

A separação entre comandos (que alteram estado) e consultas (que leem estado) se alinha naturalmente: o Process Manager emite comandos para serviços e consulta eventos para tomar decisões.

6. Desafios e Armadilhas Comuns

Concorrência e Idempotência

Eventos duplicados podem causar transições incorretas. Cada comando deve ser idempotente:

ProcessPayment(order_id, amount) deve ser seguro chamar múltiplas vezes

Escalabilidade

O Process Manager pode se tornar gargalo. Soluções:
- Particionar por chave (ex: customer_id)
- Usar processamento assíncrono com filas
- Distribuir instâncias do Process Manager

Complexidade de Manutenção

Fluxos muito longos ou aninhados tornam o código difícil de entender. Manter a máquina de estados simples e documentada é essencial.

7. Quando Adotar (e Quando Evitar) o Padrão

Cenários Ideais

  • Fluxos que envolvem 3+ serviços
  • Necessidade de rollback coordenado
  • Fluxos com dependências temporais (timeouts)
  • Requisitos de auditoria e rastreabilidade

Alternativas

  • Coreografia com mensageria: fluxos simples (< 3 serviços) sem necessidade de rollback
  • Workflow engines: para fluxos muito complexos, considere ferramentas como Temporal ou Camunda

Trade-offs

Abordagem Acoplamento Controle Complexidade
Coreografia Baixo Distribuído Baixa
Process Manager Médio Centralizado Média
Workflow Engine Alto Centralizado Alta

Referências