O carrinho abandonado tem muitos culpados conhecidos: frete surpresa, login obrigatório, formulário longo. Há um que raramente aparece no relatório, porque não é uma página nem um campo: é a distância entre o cliente e o servidor.
Cada 100ms de latência a mais no checkout é fricção num momento em que o cliente decidiu comprar e só quer concluir. E a distância é uma decisão de arquitetura, não uma fatalidade.
A matemática do checkout lento
Um checkout moderno não é uma chamada: é uma coreografia. Sessão, catálogo, carrinho, antifraude, gateway, emissão de nota, confirmação. Dezenas de requisições entre o clique em "finalizar" e a página de obrigado.
Agora some a geografia: um servidor nos Estados Unidos responde em cerca de 120ms para um usuário em São Paulo; servindo do Brasil, a resposta chega em 4ms. São mais de 100ms de viagem em cada uma das dezenas de chamadas da jornada. Multiplicado, vira segundo inteiro entre o toque no botão e a reação da tela. É exatamente nesse intervalo que o celular volátil troca de aplicativo e a venda morre sem deixar log.
Já cobrimos a régua completa em VPS no Brasil: latência de 4ms e o custo de hospedar longe. No e-commerce, a mesma régua pesa mais, porque cada milissegundo está a jusante de uma intenção de compra.
O Pix mudou a régua de novo
O cartão ensinou o brasileiro a esperar processamento. O Pix promete instantaneidade, e o cliente cobra isso na tela: o pagamento é em tempo real, e a cadeia inteira (loja, gateway, PSP, rede do Banco Central) soma suas latências até a confirmação aparecer.
Num fluxo que se vende como instantâneo, cada milissegento a mais é fricção direta num produto cuja proposta é não ter fricção. Somem-se as centrais de risco e antifraude que também falam com o checkout, e a conta de latência do e-commerce brasileiro fica mais densa que a de qualquer mercado assíncrono.
O que arquitetura transacional resolve
Latência é metade da equação; a outra metade é pico. A Black Friday aproxima-se, e ela é o exame final de qualquer loja: tráfego multiplicado, jornada completa, e cada chamada transacional.
A arquitetura transacional de alta escala existe para esse exame: separar o síncrono do assíncrono (pagamento responde, analytics espera), dar capacidade dedicada ao checkout, filar o que pode esperar, degradar com elegância o elo que falhar e escalar automaticamente com a demanda. Nada disso é exótico; é o pacote mínimo para transformar pico em receita em vez de manchete.
E o teste importa tanto quanto o desenho: hospedagem que não é testada no pico é promessa, e Black Friday não aceita promessa, aceita cronograma de simulação, correção, reteste e congelamento de mudanças.
O checklist dos 30 dias antes
- Semana 1: medir latência de ponta a ponta por jornada (não só do servidor) e mapear o elo mais lento.
- Semana 2: teste de carga com perfil real multiplicado por margem; corrigir o gargalo que aparecer.
- Semana 3: reteste, validação do plano B por elo (gateway, antifraude) e ensaio de rollback.
- Semana 4: congelamento de mudanças, monitoramento por jornada em operação e plantio definido.
Quatro semanas, um exame aprovado. O custo de pular o checklist aparece na primeira hora de pico, com juros de sazonalidade.
Conclusão
Latência não aparece no relatório de carrinho abandonado porque ela não é uma página: é o atraso entre a intenção e a resposta, multiplicado por cada chamada da jornada.
A decisão que a elimina é arquitetural e geográfica ao mesmo tempo: checkout transacional desenhado para pico, servido perto do cliente brasileiro, com dado sob LGPD e Pix respondendo na velocidade que o Pix promete. A Black Friday está a semanas de distância; a migração, a um sprint.