Contexto
Uma plataforma financeira com mais de 7 milhões de usuários. A criação de conta dependia de um provider financeiro externo, e o backend refazia automaticamente as chamadas que falhavam.
Incidente
Por volta das 10h, mais de 100 clientes falharam na criação de conta quase ao mesmo tempo. Cada um tinha sido tentado de novo mais de 10 vezes, e todos os retries falhavam com a mesma resposta do provider: “Customer Already Exists.”
Investigação
- O Command Center detectou o pico de erros no Grafana. Minha parte foram os logs.
- No AWS CloudWatch, reconstruí a sequência de chamadas ao provider para os clientes afetados, começando pela primeira requisição e não pelo erro mais recente.
- A primeira requisição tinha falhado de outro jeito: o provider criava o customer, mas não completava a conta, porque a data de vencimento era inválida.
- Isso tornava “Customer Already Exists” um erro secundário: o provider estava corretamente se recusando a criar o mesmo customer duas vezes.
- Colegas que conheciam as regras de negócio do provider confirmaram quais datas de vencimento ele rejeitava.
Causa raiz
- Criação parcial: na primeira chamada, o provider criava o customer e parava antes de criar a conta.
- Uma regra não documentada do provider: a data de vencimento não podia passar do dia 28. Nosso fluxo não aplicava essa regra.
- Os retries mascaravam a causa: cada retry repetia a criação de um customer que agora já existia, então o provider respondia “Customer Already Exists.” O motivo real só aparecia na primeira resposta, debaixo de dez ou mais falhas idênticas.
Minha contribuição
- Investiguei os logs do CloudWatch e reconstruí o fluxo de requisições dos clientes afetados.
- Identifiquei a data de vencimento inválida como a falha original, e “Customer Already Exists” como efeito colateral dos retries.
Correção e recuperação
Feito em time:
- Validação no frontend e no backend, para que datas de vencimento depois do dia 28 não cheguem mais ao provider.
- Testes automatizados para a regra do dia 28.
- Um script de recuperação para os clientes travados que pulava a criação do customer, já que o provider tinha feito essa etapa.
Resultado
- Cerca de 100 clientes recuperados.
- Resolvido em cerca de 4 horas.
- Esse erro deixou de gerar chamados depois da correção.
Lição de engenharia
Retries automáticos só são seguros quando a chamada é tudo ou nada. Quando um provider pode falhar no meio do caminho, o retry deixa de ser a mesma requisição: ele roda sobre um estado novo e recebe um erro novo. Em uma cadeia de chamadas, encontre a primeira falha de uma requisição afetada antes de confiar no erro que todo mundo está olhando, e faça a recuperação continuar a partir da etapa que já deu certo.