O Timeout de 5 Segundos que Custa 40.000€ por Dia: Arquitetura de Integração para Cadeias de Abastecimento

O efeito dominó que ninguém modela

Em engenharia de software, um timeout é um inconveniente menor. O utilizador clica em “tentar de novo.” O pedido é bem-sucedido à segunda tentativa. Ninguém repara.

Nas operações logísticas e de cadeia de abastecimento, um timeout é um evento físico. Quando um Sistema de Gestão de Armazém (WMS) não recebe a confirmação de expedição do Sistema de Gestão de Transportes (TMS) dentro da sua janela de 5 segundos, não exibe uma mensagem de erro simpática. Bloqueia o cais de carga. O camião que estava agendado para partir às 14:00 ainda está parado às 14:35. As 12 paletes destinadas àquele camião estão agora a bloquear o corredor 7. A próxima receção de mercadoria não pode ser descarregada porque o corredor 7 está bloqueado. Às 16:00, todo o armazém está em paralisia total porque uma única chamada de API devolveu um 504 Gateway Timeout.

Este é o efeito dominó que a maioria dos arquitetos de software nunca modela porque não compreendem que na logística, o fluxo de dados e o fluxo físico estão acoplados. Uma resposta de API atrasada não é apenas uma resposta atrasada. É um camião parado, uma janela de expedição perdida, uma cláusula contratual de penalização e um retalhista a jusante com prateleiras vazias.

Porque as integrações de cadeia de abastecimento são estruturalmente frágeis

A pilha de software típica para fábricas e fabricantes não é um monólito. É um mosaico de 5 a 15 sistemas independentes, cada um adquirido ou construído em momentos diferentes, por equipas diferentes, de fornecedores diferentes:

• ERP (SAP, Oracle, Microsoft Dynamics), a fonte de verdade para encomendas e inventário
• WMS (Manhattan Associates, Blue Yonder, Körber), gere as operações de armazém
• TMS (Oracle Transportation, project44, Transporeon), gere o transporte e os transportadores
• OMS (Order Management System), orquestra a satisfação de encomendas entre canais
• Gateway EDI, traduz entre formatos internos e standards EDI específicos dos parceiros (EDIFACT, ANSI X12)

Cada sistema expõe a sua própria API (ou, no caso de ERPs legados, um drop de ficheiros flat-file via SFTP). A integração entre eles é normalmente construída como chamadas REST síncronas ponto-a-ponto. O Sistema A chama o Sistema B. O Sistema B chama o Sistema C. Se algum elo da cadeia estiver lento ou não responder, todo o fluxo pára.

# A cadeia síncrona frágil
┌─────┐     ┌─────┐     ┌─────┐     ┌─────┐
│ OMS │────▶│ ERP │────▶│ WMS │────▶│ TMS │
└─────┘     └─────┘     └─────┘     └─────┘
   │           │           │           │
   └───────────┴───────────┴───────────┘
    Se QUALQUER elo falhar, tudo pára.

O Circuit Breaker não é suficiente

A solução de engenharia padrão para falhas em cascata é o padrão Circuit Breaker. Quando um serviço downstream falha repetidamente, o circuito “abre” e os pedidos subsequentes falham imediatamente em vez de esperar pelo timeout. Isto previne o esgotamento de threads no serviço chamador.

// Uma implementação básica de circuit breaker
class CircuitBreaker {
  constructor(fn, { threshold = 5, resetTimeout = 30000 } = {}) {
    this.fn = fn;
    this.failures = 0;
    this.threshold = threshold;
    this.resetTimeout = resetTimeout;
    this.state = 'CLOSED'; // CLOSED = normal, OPEN = a bloquear
  }
  
  async call(...args) {
    if (this.state === 'OPEN') {
      throw new Error('Circuito ABERTO  -  serviço downstream indisponível');
    }
    
    try {
      const result = await this.fn(...args);
      this.failures = 0; // Reset em caso de sucesso
      return result;
    } catch (error) {
      this.failures++;
      if (this.failures >= this.threshold) {
        this.state = 'OPEN';
        setTimeout(() => {
          this.state = 'HALF-OPEN'; // Permitir um pedido de sondagem
          this.failures = 0;
        }, this.resetTimeout);
      }
      throw error;
    }
  }
}

O Circuit Breaker previne o colapso do sistema. Mas no contexto de uma cadeia de abastecimento, “falhar rápido” não é um resultado aceitável. Quando o TMS está inacessível, o armazém não pode simplesmente ignorar a expedição. Os bens físicos existem. Têm de ir para algum lado. A operação precisa de uma estratégia de modo degradado, não apenas de um mecanismo de fail-fast.

A arquitetura assíncrona que realmente funciona

As plataformas de cadeia de abastecimento que lidam com volumes elevados de forma fiável (os sistemas internos da DHL, a rede de fulfillment da Amazon, a infraestrutura de reservas da Maersk) partilham todas um princípio arquitetónico comum: comunicação assíncrona orientada a eventos com entrega garantida.

Em vez do Sistema A chamar sincronamente o Sistema B e esperar por uma resposta, o Sistema A publica um evento num message broker (RabbitMQ, Apache Kafka, AWS SQS). O Sistema B consome o evento ao seu próprio ritmo. Se o Sistema B estiver temporariamente em baixo, a mensagem espera na fila. Nenhum dado é perdido. Nenhum timeout ocorre. Nenhum efeito dominó.

# Fluxo de cadeia de abastecimento orientado a eventos
EncomendaCriada:
  → publicar para: fila order.created
  → WMS consome: cria lista de picking
  → WMS publica: pick.completed
  → TMS consome: reserva transportador
  → TMS publica: shipment.booked
  → OMS consome: atualiza estado da encomenda
  → Gateway EDI consome: envia ASN ao retalhista

A decisão de design crítica é a idempotência. Num sistema baseado em mensagens, as mensagens podem ser entregues mais do que uma vez (at-least-once delivery). Cada consumidor deve ser desenhado para tratar mensagens duplicadas graciosamente. Se o WMS receber dois eventos order.created com o mesmo ID de encomenda, deve reconhecer o duplicado e ignorá-lo em vez de criar duas listas de picking.

Transações compensatórias em sistemas físicos

No e-commerce, uma transação falhada significa um reembolso. Na logística, uma transação falhada significa bens físicos no local errado. As transações compensatórias (o mecanismo para “desfazer” um passo num fluxo de trabalho distribuído) são fundamentalmente mais difíceis quando o fluxo envolve movimento físico.

Consideremos um cenário comum: o OMS aloca inventário do Armazém A. O WMS começa o picking. A meio do processo, o TMS reporta que não existe transportador disponível para a data de entrega exigida a partir do Armazém A, mas existe um disponível a partir do Armazém B.

Numa arquitetura síncrona, isto é um deadlock. O WMS já começou o picking. O TMS não consegue encaminhar a expedição. A encomenda fica presa.

Numa arquitetura orientada a eventos com consultoria técnica adequada, isto é tratado por um orquestrador Saga, um motor de fluxos de trabalho com estado (AWS Step Functions, Temporal, ou uma implementação personalizada) que gere a compensação:

1. Publicar pick.cancel para a fila WMS do Armazém A
2. Esperar pela confirmação pick.cancelled
3. Publicar inventory.reallocate para o ERP apontando para o Armazém B
4. Publicar pick.initiate para a fila WMS do Armazém B
5. Retomar o fluxo normal

Cada passo é uma ação discreta e compensável. Se qualquer passo falhar, o orquestrador sabe exatamente que ações compensatórias executar para devolver o sistema a um estado consistente.

O investimento em infraestrutura que se paga a si próprio

O custo de construir uma arquitetura de integração assíncrona e orientada a eventos para operações de cadeia de abastecimento B2B é significativo. Requer infraestrutura de message broker, consumidores idempotentes, filas dead-letter, monitorização e um orquestrador Saga. É um investimento de engenharia de 3 a 6 meses.

Mas a alternativa é o timeout de 5 segundos que custa 40.000€ por dia. Nas operações de cadeia de abastecimento, o retorno do investimento em arquitetura de integração resiliente não é teórico. É a diferença entre um armazém que expede 10.000 encomendas por dia e um que paralisa completamente porque uma API de TMS devolveu um 504.