Às 12:03 AM, a curva de pedidos na tela de monitoramento subiu como se alguém tivesse acendido um pavio. Às 12:07 chegou o primeiro 429: a API de etiquetas da transportadora começou a limitar o tráfego. Às 12:12, a API de coleta de pedidos do marketplace também passou a recusar de forma intermitente. No chão de fábrica, uma dúzia de embaladores esperava pelas etiquetas de envio enquanto as impressoras guardavam um silêncio inquietante. O rapaz de TI reiniciava trabalhos e digitava "sem pânico" no chat do grupo, e dava para ver que ele estava em pânico. Naquela noite sobrevivemos duas horas com folhas de separação escritas à mão, e o atendimento ao cliente não parou de tocar no dia seguinte.
Esta não é uma história sobre software mal escrito. É simplesmente o que a temporada de pico faz: um sistema que chama uma API de terceiros dezenas de milhares de vezes por dia pode atingir mais de dez vezes esse volume em uma única noite. Toda API de terceiros tem cotas, e quando você as estoura, o outro lado não negocia — ele simplesmente diz não. Os pedidos param de entrar, as etiquetas param de imprimir, o estoque para de sincronizar, e toda a sua operação trava diante dos servidores de outra empresa. Este artigo pula a teoria. Eis o que você realmente faz antes da temporada de pico.
As cotas que ninguém lê até a noite em que elas te matam
Primeiro: encontre a cota de cada API de terceiros que você chama e anote os números. API de etiquetas das transportadoras, coleta de pedidos dos marketplaces, sincronização de estoque do ERP, notificações por SMS — cada uma limita de um jeito. Algumas por minuto, outras por dia, algumas por conta, outras por IP. Não confie na memória. Não "ache que são algumas centenas por minuto". Abra a documentação oficial, copie os números, anote as unidades.
Segundo: faça as contas. Pegue o pico da temporada passada — ou um ensaio menor, como uma promoção de meio de ano — multiplique por 1.5 e calcule quantas chamadas você vai disparar naquela hora da meia-noite. Conte chamadas, não pedidos: um único pedido pode significar três ou quatro chamadas de API (consulta de tarifa, etiqueta, envio de rastreio, atualização de estoque), e esse multiplicador assusta a maioria das pessoas na primeira vez que calculam. Coloque o resultado ao lado da cota e a diferença encara você de volta.
Terceiro: solicite aumentos de cota com antecedência. As grandes plataformas e transportadoras aceitam aumentos pré-pico, mas há um processo e uma fila — duas a três semanas de antecedência é bom senso. Não envie só um número; anexe seus cálculos. O engenheiro que analisar seu pedido responde muito melhor a "volume de chamadas no horário de pico, duração, detalhamento por endpoint" do que a "por favor aumentem nossa cota". Uma eu aprendi do jeito difícil: um ano aumentamos a cota da nossa transportadora principal e esquecemos a rota de backup. Na noite de pico, a principal oscilou, o tráfego fez failover, e a cota do backup estourou na hora. Toda aquela preparação, desperdiçada. Cubra cada conta e cada rota que você realmente vai chamar — incluindo os backups.
Tentativas não deveriam ser galinhas sem cabeça
Um aumento de cota não te deixa à prova de balas. A noite de pico sempre traz surpresas: os servidores do outro lado oscilam, pacotes se perdem, um endpoint degrada sem aviso. A forma como sua lógica de tentativas está escrita decide se você passa deslizando ou termina o serviço de derrubá-los.
Nunca escreva tentativas burras em intervalo fixo. Cada requisição falha tentando de novo a cada cinco segundos só joga a enchente de volta contra o muro — no momento em que o outro lado recupera o fôlego, você o derruba de novo. Use backoff exponencial: espere um segundo, depois dois, depois quatro, dobrando para cima, com um pouco de jitter aleatório misturado. As pessoas pulam o jitter e não deveriam: sem ele, todos os clientes tentam de novo no mesmo instante e você ganha uma nova enchente sincronizada. Com ele, as tentativas se espalham.
O backoff também precisa de um teto: um número máximo de tentativas e uma espera total máxima, após os quais você desiste e degrada. Tentativa infinita é o padrão mais perigoso que existe. Uma vez vi uma fila de tentativas crescer até comer a memória do servidor de aplicação — nosso próprio sistema caiu antes de a API do fornecedor se recuperar. Trave o número de tentativas e os tempos de espera na configuração durante os testes de carga. Editar configuração na noite de pico é jogar na loteria.
E trate leituras e escritas de forma diferente. Tentar de novo uma coleta de pedidos é barato. Tentar de novo uma impressão de etiqueta ou um decremento de estoque não é: então pergunte sobre idempotência antes de tentar uma escrita de novo. Se o mesmo pedido imprime duas vezes, a transportadora deduplica ou você recebe duas etiquetas? Você é cobrado duas vezes? Ninguém faz essas perguntas numa terça-feira calma; a noite de pico vai ensinar a lição por você. Chaves de idempotência pertencem a toda chamada de escrita que toca dinheiro ou mercadoria física. Não descubra duplicatas na conciliação.
Quando quebrar de verdade, degrade com dignidade
Backoff e filas compram tempo. A degradação admite a realidade: a API deles caiu e seu armazém não pode parar. O plano de degradação é escrito e ensaiado antes da temporada de pico — não inventado às 12:12 AM.
A jogada principal é "pegue o pedido agora, sincronize depois". Não consegue coletar os pedidos do marketplace? Produza a partir dos pedidos em cache local, imprima etiquetas na transportadora de backup e preencha os dados quando a API se recuperar. Sincronização de estoque travada? Continue enviando, registre as divergências, reconcilie à mão depois. Um princípio: proteja a linha vital — a mercadoria saindo pela porta. Tudo que não for em tempo real pode atrasar.
A degradação deveria ter níveis. Leve: mate as chamadas não críticas — passe as notificações por SMS para um lote pós-pico e libere a cota para a impressão de etiquetas, a chamada que te mantém vivo. Média: faça failover para a rota de backup mesmo que seja mais lenta ou mais cara. Pesada: vá para o manual — etiquetas em branco preenchidas à mão, separações dirigidas por planilha. Parece primitivo, mas quando você está lá, um plano primitivo vence encarar uma tela morta. O gatilho e os passos de cada nível cabem em uma página impressa colada na mesa de plantão. Ninguém pensa com clareza à meia-noite na noite de pico.
Por baixo de tudo há uma fila. Toda chamada que normalmente vai direto a um terceiro deveria passar primeiro por uma fila local durante o pico, consumida num ritmo constante abaixo da cota. Defina marcas de alerta na profundidade da fila: passada a linha, a degradação leve entra automaticamente. Construa isso em tempos normais, não na semana antes do pico — a estabilidade da própria fila e seu monitoramento precisam de tempo para se provar.
A duas semanas, percorra esta lista
Eis o checklist pré-pico, pronto para marcar: cada cota de terceiros anotada; volume de chamadas de pico calculado; pedidos de aumento protocolados, rotas de backup incluídas; política de tentativas ativa — backoff exponencial com jitter e teto rígido; idempotência das chamadas de escrita confirmada; os três níveis de degradação escritos e ensaiados uma vez; a fila de suavização ativa com marcas de alerta definidas; a escala de plantão e o caminho de escalação publicados.
Uma coisa que você pode fazer amanhã: abra a configuração de integração de terceiros do seu sistema, encontre o limite de cota de cada API e monte a tabela. Essa única tabela é a diferença entre dormir na noite anterior à temporada de pico e viver outra noite como a com que abri este artigo.
Traduzido do inglês. Em caso de divergência, prevalece a versão em inglês.
