À 1h da manhã da Black Friday de novembro de 2024, o OMS de um 3PL transfronteiriço de cosméticos no leste da China começou a disparar timeouts de API em massa. O primeiro instinto do engenheiro de plantão foi adicionar retries — reenviar após um timeout de 5 segundos, até 3 tentativas. Às 3h da manhã, toda a cadeia havia colapsado: o WMS não conseguia obter confirmações de pedidos, o TMS não conseguia consultar faturas de frete, e os status das tarefas de picking ficaram 40 minutos sem reporte. O armazém recorreu à conciliação manual. Não foi um incidente isolado; é um roteiro recorrente em integrações de sistemas de armazém. Um timeout de API, transformado por retries bem-intencionados em uma tempestade de retries.
O fenômeno: como um timeout se transforma em colapso em cadeia
A cronologia daquela noite é instrutiva. A venda da meia-noite da Black Friday explodiu o volume de pedidos do OMS; a API de admissão de pedidos do WMS ficou lenta e surgiram timeouts de 5 segundos. A lógica de retry do WMS estava codificada de forma rígida: reenviar imediatamente em caso de timeout, 3 tentativas. Mas a consulta de faturas de frete do TMS sofria a mesma carga de pico, e o tráfego de retries do WMS multiplicou várias vezes a taxa de consultas ao TMS. O TMS cedeu e martelou a API de rastreamento da transportadora, acionando seu limitador de taxa. Uma vez limitado, os callbacks se acumularam em fila e cada atualização de status de picking do WMS travou — um timeout em um elo, amplificado salto a salto pelos retries de cada camada, até derrubar toda a cadeia.
A literatura pública de design de sistemas nos permite quantificar essa amplificação. Suponha que a cadeia de chamadas tenha 4 saltos (OMS → WMS → TMS → API da transportadora) e cada salto tente novamente duas vezes em caso de timeout. No pior caso, o serviço mais a jusante enfrenta 3 × 3 × 3 = 27 vezes seu volume normal de requisições. Uma API saudável a 200 QPS de repente encara 5,400 QPS — enquanto os limites de taxa das transportadoras costumam ser fixados em apenas 2–3× o pico normal. É um cálculo ilustrativo, mas explica por que o TMS caiu primeiro naquela noite: não enfrentava "um pouco mais" de tráfego, mas um esmagamento de uma ordem de magnitude.
Um segundo caso merece igual atenção. O TMS de um 3PL chamava a API de rastreamento de uma transportadora com timeout de 30 segundos e sem circuit breaker. Na alta temporada, as requisições ficavam penduradas em timeouts de 30 segundos, o pool de threads encheu, e os callbacks de status do WMS não conseguiam nenhuma thread — ficaram em fila por 40 minutos. A causa raiz não era realmente o timeout; era que as requisições com timeout continuavam ocupando threads. Timeouts longos machucam a jusante mais do que os curtos — uma conclusão que muitos engenheiros têm ao contrário.
Os números: a amplificação dos retries assusta mais do que parece
Levemos o cálculo um passo adiante. O poder destrutivo de uma tempestade de retries vem de dois multiplicadores que se combinam: a profundidade — cada salto extra multiplica a amplificação por outra contagem de retries; e a duração — quanto mais longo o timeout, mais tempo cada requisição pendurada retém recursos, e mais curta a janela de recuperação a jusante. Segundo a análise de 2015 do AWS Architecture Blog em "Exponential Backoff And Jitter", retries de ritmo fixo escondem outro assassino: a sincronização. Cada cliente expira no mesmo momento e tenta novamente no mesmo momento, ressoando em ondas — mal a jusante recupera o fôlego, a próxima onda chega.
Então o colapso daquela noite não foi "tráfego demais", mas "retries sincronizados demais". O OMS, o WMS e o TMS usavam o mesmo modelo — timeout de 5 segundos, 3 retries imediatos — pulsando em perfeita sincronia, como três multidões se espremendo por uma porta ao mesmo tempo. É também por isso que muitos postmortems concluem "adicionar servidores" e veem pouca melhora: servidores adicionam capacidade, enquanto tempestades consomem janelas de tempo de recuperação. Dimensões diferentes.
A atribuição: quatro mecanismos de retry, e por que só "backoff + jitter + breaker" sobrevive
Alinhadas lado a lado, as estratégias de retry comuns contam uma história clara:
| Estratégia | Mecanismo | Amplificação | Falha fatal |
|---|---|---|---|
| Retry imediato | Reenviar na hora, até N vezes | N×, cresce com a duração da indisponibilidade | A segunda onda chega antes de a jusante se recuperar |
| Retry em intervalo fixo | Reenviar a cada T segundos | N×, escalonamento limitado | Todos os clientes tentam em sincronia — ressonância |
| Backoff exponencial | As esperas crescem 2s → 4s → 8s | Decai com o tempo, dá margem de respiro | Não corrige a sincronização dos retries |
| Backoff + jitter | Backoff mais jitter aleatório | Decai e dessincroniza | Um pouco mais complicado de implementar corretamente |
| Circuit breaker + fallback | Abre além de um limiar de taxa de falhas, sondas half-open | Quase zero | Exige um caminho de fallback projetado |
O valor do backoff é "cada vez mais devagar", comprando tempo de recuperação; o valor do jitter é quebrar a sincronização — o verdadeiro combustível de uma tempestade de retries não é tentar de novo em si, mas cada cliente tentar no mesmo segundo. O circuit breaker, um padrão que Michael Nygard introduziu em Release It!, abre o circuito além de um limiar de taxa de falhas, para de enviar requisições, e faz sondas half-open antes de deixar o tráfego passar de novo. Para integrações WMS-transportadora, é quase obrigatório: martelar uma API de transportadora limitada só coloca você na lista de bloqueio deles.
Mais uma regra subestimada: só endpoints idempotentes merecem retries. Operações de escrita como criação de pedidos ou dedução de estoque, repetidas sem chave de idempotência, podem virar pedidos duplicados e deduções duplicadas — muito mais caras que um timeout. Muitos documentos de integração WMS/OMS escrevem casualmente "tentar 3 vezes" sem nunca responder a "e se o pedido passar duas vezes?".
Na prática: três regras para integrações de sistemas de armazém
Primeiro, escalone seus timeouts. Consultas de borda recebem 3 segundos, APIs centrais de pedidos 10 segundos, e reconciliações pesadas em lote evitam por completo o HTTP síncrono em favor de filas assíncronas. Timeouts mais longos não são mais tolerantes — retêm recursos por mais tempo.
Segundo, escreva a política de retry no documento de integração, não nos padrões do código. Base do backoff, faixa de jitter, tentativas máximas, limiares do breaker — quatro números para alinhar com montante e jusante durante os testes de integração. O colapso daquela noite aconteceu, diretamente, porque três camadas compartilhavam uma configuração modelo e ninguém considerou a ressonância.
Terceiro, limite a jusante e isole bulkheads. A consulta de faturas de frete do TMS e os callbacks de status do WMS não deveriam compartilhar um pool de threads; um saturado não deve matar o outro. A limitação do lado do cliente nas APIs externas das transportadoras também importa — o limite de taxa delas protege elas; o seu protege você.
Um julgamento contraintuitivo merece ênfase: após um timeout, "esperar mais antes de tentar de novo" costuma ser pior que "falhar rápido e deixar o chamador enfileirar". Pools de threads morrem por ocupação concorrente, não por contagem de retries. Uma requisição ocupando uma thread por 30 segundos machuca a jusante mais que um timeout de 3 segundos mais 2 retries. Timeouts curtos, poucos retries, falha rápida exposta ao chamador para enfileirar — aparentemente pior UX, mas a escolha mais responsável para toda a cadeia.
A tendência é clara: o retry está migrando de "responsabilidade do chamador" para "capacidade da infraestrutura". Filas de mensagens mortas (dead-letter queues), o padrão outbox e service meshes empurram a política de retry para a camada de infraestrutura, e o código de negócio cada vez escreve menos lógica de retry à mão. É progresso — uma causa raiz das tempestades é cada equipe escrever seus próprios retries, ritmos nunca alinhados. No dia em que a lógica de retry desaparecer por completo do código de negócio, as tempestades estarão verdadeiramente domadas. Até lá, a seção de "estratégia de retry" do seu documento de integração WMS merece uma reescrita — agora.
Por Dr. Chen, pesquisador da cadeia de suprimentos
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
