Checkout lento no pico de acesso quando o gargalo está fora do seu servidor: frete, gateway, antifraude e ERP

Catálogo abrindo rápido, CPU da VPS baixa e o cliente travado no cálculo de frete ou na finalização do pedido: o recurso que acabou não é a sua máquina, é o processo da loja parado esperando a resposta de uma API de terceiro. Aí mais servidor não resolve — conter a espera resolve.

Checkout lento no pico de acesso, com o catálogo abrindo rápido e a CPU da VPS baixa, quase nunca é falta de máquina: é o processo da loja parado esperando a resposta de uma API de terceiro — frete, gateway de pagamento, antifraude ou ERP. Mais servidor não resolve; conter a espera resolve.

• Catálogo rápido, CPU baixa e checkout travado é a assinatura de espera por serviço externo, não de falta de servidor.
• Enquanto a loja espera o terceiro, o processo que atende aquele cliente fica ocupado sem consumir CPU; por isso poucas pessoas no checkout bastam para ocupar todos os atendentes e derrubar até a home.
• A espera aparece no tempo de resposta medido por rota e nas linhas de timeout do log da aplicação; a média do site inteiro esconde exatamente a rota lenta.
• Timeout curto com falha definida, cache de cotação por CEP e peso, fila assíncrona para o que não é tempo real e integração não essencial desligada no dia do pico: cada uma resolve uma parte, nenhuma resolve todas.
• Subir servidor extra não conserta gargalo de terceiro e pode piorar, porque mais réplicas fazem mais chamadas contra uma API que tem limite de requisições.

Checkout lento no pico de acesso: por que só essa rota degrada

Sintoma localizado em uma rota aponta para o que só aquela rota faz: se o catálogo está normal e a lentidão está no cálculo de frete, na finalização do pedido ou na confirmação de pagamento, o candidato é uma chamada a serviço externo que passou a demorar.

O checkout não é uma página só sua: nele entram serviços de outras empresas, cada um respondendo no tempo dele:

• Transportadora ou agregador de frete — cotação por CEP, peso e dimensão, a cada alteração do carrinho.
• Gateway de pagamento — autorização do cartão, que só termina quando bandeira e emissor respondem.
• Antifraude — análise de risco do pedido antes da aprovação.
• ERP — baixa de estoque, cadastro do cliente, emissão de nota.

O pico é seu, mas também é deles: Black Friday é Black Friday para a API da transportadora, para o antifraude e para o ERP. A resposta que levava frações de segundo no dia comum passa a levar segundos no dia em que você tem gente no site. O quadro geral está no checklist de lentidão sob carga.

O trabalhador que fica ocupado sem fazer nada: a chamada externa bloqueante

A sua loja atende com um número fixo de trabalhadores — no mundo PHP, os workers do PHP-FPM, processos em quantidade definida na configuração. Cada visita ocupa um worker do início ao fim da resposta.

Chamada bloqueante é quando o código pede a cotação de frete e para ali até a resposta chegar: o worker continua alocado àquele cliente, ocupado mas sem trabalhar — na linha, esperando a outra empresa atender.

Daí o sinal mais contraintuitivo: CPU baixa e loja lenta ao mesmo tempo. O que acabou não foi processador, foi disponibilidade de atendente — cada segundo a mais na resposta da API é um atendente parado naquela rota, inclusive para quem só simulava frete e nunca vai comprar.

Servidor no teto ou terceiro lento: os sinais que separam os dois casos

A resposta é oposta em cada caso, então vale separar antes de gastar:

Dois testes caseiros confirmam a suspeita. O primeiro: cronometrar a URL do serviço externo chamada direto do servidor, com a loja parada e com movimento; se demora igual, a lentidão não é sua. O segundo: desligar uma integração não essencial em ambiente de teste — nunca em produção no meio da campanha — e refazer o tempo do checkout; se cai, você achou o responsável.

Vale ler o código de erro com a ajuda de o que 502, 503 e 504 significam: 504 na loja inteira e 504 só na rota de pagamento contam histórias diferentes.

Onde a espera externa aparece: tempo por rota, log e lista de processos

• Tempo de resposta por rota, não média do site. A média esconde a rota de frete lenta debaixo de milhares de páginas de catálogo rápidas. Meça separado carrinho, finalização do pedido e endpoint de cotação.
• Campo de tempo no log do servidor web. Nginx e Apache registram o tempo de cada requisição, mas o campo costuma não vir ativado no formato padrão. Ligue antes do pico.
• Log de erro da aplicação. Timeouts de conexão HTTP e de cURL — connection timed out, operation timed out — trazem o endereço do serviço na própria linha.
• Lista de processos durante o pico. Workers todos ocupados com CPU baixa é a assinatura da espera; com CPU no teto é outra coisa, e o remédio é outro.

Sem linha de base nada disso significa muito: saber que a rota de frete leva alguns segundos só vira diagnóstico quando você sabe quanto levava no dia comum — assunto de monitoramento de VPS, feito antes do pico.

Efeito fila: por que poucos clientes no checkout derrubam a loja inteira

A conta é direta: o número de atendentes dividido pelo tempo de ocupação dá quantos pedidos por segundo a loja aguenta naquela rota. Ilustração do mecanismo, não medida de loja nenhuma: vinte workers e uma cotação de quatro segundos dão cinco pedidos por segundo — vinte pessoas simultâneas no frete já ocupam tudo.

Ocupados todos os atendentes, a fila passa a incluir quem só queria ver produto: a home cai por culpa da integração de frete. Não é volume de tráfego, é tempo de ocupação — por isso o Analytics mostra pouca gente no site e a loja está de joelhos.

Quem quiser medir o próprio teto nessa rota precisa de teste de carga com cenário de checkout: teste que só busca a página inicial mede a parte da loja que nunca foi o problema.

Timeout, cache de frete, fila assíncrona e integração desligada: o que cada medida muda

• Timeout curto. Definir quanto tempo a loja espera antes de desistir e o comportamento de falha: frete indisponível com opção padrão, mensagem clara, nunca tela branca. Não torna o terceiro rápido — impede que ele segure a sua loja.
• Cache do cálculo de frete por CEP e peso. A mesma combinação repetida não precisa de nova cotação; guardar a resposta por um tempo curto corta parte do volume. Não resolve a autorização de pagamento, única por pedido. O que pode e o que não pode sair de cache está em o que o cache absorve e o que sobra para o servidor.
• Fila assíncrona. O que não precisa acontecer com o cliente na tela — envio ao ERP, emissão de nota, e-mail transacional, sincronização de estoque — sai do caminho do checkout e roda depois. Exige um processo que consuma a fila e trate o que falhar lá atrás.
• Desligar integração não essencial no dia do pico. Chat, recomendação, pixel do lado do servidor, relatório em tempo real. É decisão de negócio, e essa lista entra na preparação feita antes da campanha, não no meio da queda.

O limite honesto: pagamento e antifraude em geral precisam ser síncronos, por regra do fornecedor e por risco de fraude. Aceitar pedido sem autorização do cartão transfere o problema para o financeiro.

Por que subir servidor extra piora gargalo de terceiro — e quando o burst volta a ajudar

Mais réplicas fazem mais chamadas simultâneas contra a mesma API, que tem limite de requisições por minuto ou por contrato. O resultado pode ser bloqueio por limite de taxa ou respostas ainda mais lentas para todo mundo — o mesmo mecanismo do gargalo de banco de dados na VPS: multiplicar quem pede não multiplica quem responde.

Burst é subir máquinas extras na nuvem pública só durante o pico e removê-las quando a demanda cai, mantendo a operação normal na VPS fixa. Faz sentido quando a espera externa já está contida e a aplicação continua batendo no teto de CPU e de processos: aí falta máquina de verdade, e o que precisa existir para escalar está em auto scaling em VPS.

A ordem de trabalho quando a lentidão do checkout vem de fora

1. Medir tempo de resposta por rota, separando checkout e cotação do resto do site.
2. Identificar qual chamada externa está segurando, pelo log de erro e pelo teste direto do servidor.
3. Aplicar timeout com comportamento de falha definido e visível para o cliente.
4. Cachear o que se repete — cotação por CEP e peso.
5. Empurrar para fila o que não é tempo real: ERP, nota, e-mail, estoque.
6. Só então avaliar capacidade de máquina.

O erro caro é inverter essa ordem: contratar máquina maior para um problema que a máquina não tem. A fatura sobe, o checkout continua igual e o pico passa. Se depois de conter a espera externa o teto medido continuar abaixo do pico esperado, aí a conversa é sobre reforço por hora no dia da campanha.

Falar sobre o piloto do primeiro pico no WhatsApp

Perguntas frequentes

Como saber se o problema é do meu servidor ou de quem fornece o frete?

Compare os sinais: se só o checkout degrada enquanto a home fica rápida e a CPU está baixa, aponta para serviço externo. Se todas as páginas ficam lentas e a CPU no teto, é falta de servidor.

Faça dois testes: chame a URL do frete direto do seu servidor e cronometre com a loja parada e com movimento — se demora igual, a lentidão vem de lá mesmo. Segundo: desative a integração em ambiente de teste e refaça o tempo do checkout; se cai de vez, você achou o culpado.

Aumentar o servidor resolve lentidão causada por integração de terceiro?

Não. Mais réplicas da aplicação fazem mais chamadas simultâneas contra a mesma API, que tem limite de requisições. O resultado pode ser bloqueio por limite de taxa ou respostas ainda mais lentas para todo mundo.

A regra é simples: o que é replicável resolve com máquina; o que é recurso único de terceiro, não. Burst volta a fazer sentido só depois de conter a espera externa com timeout, cache e fila — aí, se a aplicação ainda bater no teto de CPU, falta máquina de verdade.

Posso processar o pagamento depois e não durante o checkout?

Não para pagamento. Pagamento e antifraude precisam ser síncronos por regra do fornecedor e por risco de fraude — aceitar pedido sem autorização do cartão transfere o problema para o financeiro.

Mas outras integrações podem ir para fila assíncrona: ERP, emissão de nota, e-mail transacional e sincronização de estoque saem do caminho do checkout e rodam depois, liberando o atendente rápido.

O que fazer quando o gateway de pagamento dá timeout no pico?

Defina um timeout curto na chamada — quanto tempo a loja espera antes de desistir — e decida o comportamento de falha: frete ou pagamento indisponível com opção padrão, mensagem clara para o cliente, nunca tela branca. Isso libera o atendente rápido.

Mas timeout sozinho não torna o gateway rápido; só impede que ele segure a sua loja. A ordem completa é: medir tempo por rota, identificar qual chamada segura, aplicar timeout, cachear o que se repete, empurrar para fila o que não é tempo real e só depois avaliar capacidade de máquina.