Latência

Latência é o tempo entre o envio de uma requisição e a chegada da resposta. Em sistemas em rede é medida em milissegundos; em sistemas distribuídos às vezes em microssegundos; na latência percebida pelo usuário, em centenas de milissegundos onde os humanos começam a notar.

Três medições que todo engenheiro deve conhecer sobre a latência de um serviço:

• Latência média. Geralmente enganosa. Um único outlier lento a puxa para cima.
• Latência mediana (p50). A experiência da requisição típica. Mais honesta que a média.
• Latências de cauda (p95, p99, p99,9). O 95º, 99º, 99,9º percentil dos tempos de resposta. p99 significa “1% das requisições são mais lentas que isso.” Para sistemas voltados ao usuário, o p99 captura a experiência dos usuários azarados.

Por que as caudas importam: em escala, todo usuário atinge a cauda eventualmente. Um serviço com p50 de 100ms e p99 de 5000ms tem desempenho típico rápido e travamentos ocasionais de 5 segundos. Um usuário fazendo 100 requisições em uma sessão provavelmente atingirá a cauda pelo menos uma vez.

Fontes de latência em uma requisição HTTP típica:

• DNS: 1-50 ms primeira consulta, ~0 em cache.
• Handshake TCP: 1 round-trip time (RTT).
• Handshake TLS: 1-2 RTTs adicionais.
• Processamento do servidor: altamente variável, de microssegundos a segundos.
• Propagação de rede: ~5ms NY-Chicago, ~70ms NY-Londres, ~150ms NY-Sydney. Limite inferior é a velocidade da luz.

Para desempenho de API no mundo real, a distribuição por percentil importa muito mais que a média. Reportar apenas a latência média é uma das formas clássicas pelas quais os painéis de monitoramento enganam.

Por que p99 é a métrica que define “parece quebrado”: um serviço com 99% das requisições abaixo de 100 ms mas 1% levando 5 segundos parece quebrado para todo usuário que eventualmente atinge o caminho lento. A matemática: se um carregamento típico de página faz 50 chamadas de backend e o p99 é 5 s, então a probabilidade de o usuário atingir pelo menos uma chamada lenta é 1 − (0,99)⁵⁰ ≈ 40%. Quase uma página em cada duas é lenta. Melhorar a mediana é invisível; reduzir o p99 melhora diretamente o desempenho percebido. O manual SRE do Google codificou esse princípio (“a latência de cauda é a latência”), e a convenção se espalhou pela indústria. Referência: Dean & Barroso — The Tail at Scale (CACM, 2013).

Exemplo prático: alocação de orçamento em uma requisição

Alvo: 200 ms p95 para uma página de checkout de um usuário nos EUA. O RTT NY-Londres limitado pela velocidade da luz é de aproximadamente 70 ms; esse é o piso para qualquer chamada transatlântica. Um fanout típico: 50 ms TLS + economias de reutilização de conexão, 40 ms leitura de BD regional, 60 ms autorização de pagamento de terceiros, 20 ms renderização HTML, 30 ms hidratação no cliente. Somando-os ingenuamente chega-se a 200 ms — sem margem para retentativas, pausas de GC ou picos de vizinho barulhento. A correção é estrutural: mover a chamada de pagamento para fora do caminho crítico (adiar para pós-redirecionamento), armazenar em cache a leitura do BD na borda por 60 s e usar HTTP/3 sobre QUIC para dobrar o TLS na configuração da conexão. Cada um economiza 30-50 ms na cauda.

Como instrumentar corretamente

Agregar pela média descarta exatamente a forma da distribuição que você precisa. Amostre tempos brutos ou use histogramas HDR (biblioteca HdrHistogram de Gil Tene, portada para a maioria das linguagens) que preservam percentis com eficiência. Calcule percentis por região, por endpoint, por versão — uma regressão de 5 ms de p99 global pode significar uma regressão de 200 ms em uma única região mascarada pela média. Fique atento à “omissão coordenada”: geradores de carga que esperam uma requisição lenta antes de emitir a próxima subestimam o p99 por ordens de magnitude. Veja também percentil e mediana. Para decomposição de RTT em nível de protocolo, a especificação RFC 9000 QUIC documenta o estabelecimento de conexão 0-RTT e 1-RTT que reduz materialmente a latência de handshake.