Latência, vazão e percentis: o guia que resolve a discussão

Existe uma frase que aparece em toda reunião técnica e que não significa nada: "o sistema está lento".

Lento para quem? Em qual momento? Comparado a quê? Enquanto essas perguntas não forem respondidas com número, a conversa é sobre sensação. E sensação não se otimiza.

Latência não é vazão#

Latência é quanto tempo uma requisição demora. Medida em milissegundos. É a experiência de uma pessoa.

Vazão é quantas requisições cabem por segundo. Medida em QPS. É a capacidade do sistema.

A analogia da estrada funciona: latência é quanto tempo o seu carro leva do Rio a São Paulo, vazão é quantos carros passam pelo pedágio por hora. Você pode dobrar a vazão construindo mais pistas, e a sua viagem continua durando exatamente o mesmo tempo.

Por que isso importa na prática: quando alguém reporta lentidão, a primeira pergunta é qual dos dois mudou.

• Latência subiu, vazão igual → alguma dependência ficou mais lenta. Procure fora do seu código.
• Vazão bateu num teto e a latência disparou junto → você saturou. Tem fila crescendo em algum lugar: balanceador, pool de conexões, executor de tarefas.

São dois diagnósticos completamente diferentes, e distinguir os dois leva trinta segundos se você tiver os gráficos certos.

A Lei de Little#

Existe uma relação entre os dois que resolve metade das discussões sobre dimensionamento:

requisições em andamento = vazão × latência

Cem requisições por segundo, duzentos milissegundos cada, dá vinte requisições vivas ao mesmo tempo.

Esse número te diz quantas threads você precisa, quantas conexões de banco, quanto de qualquer recurso que fique ocupado durante a requisição. É uma multiplicação — não é modelagem, não é chute.

E ela expõe uma armadilha: se a latência dobrar, o número de requisições em andamento dobra, mesmo com o mesmo tráfego. É por isso que uma dependência lenta esgota o seu pool de threads num dia em que o volume não mudou nada.

Média mente. Percentil não.#

Se eu disser que a latência média da minha API é 100ms, você não sabe quase nada.

Imagine dez requisições: nove levaram 10ms e uma levou 900ms.

d = [10]*9 + [900]
media = sum(d) / len(d)   # 99.0  -> parece ótimo

A média dá 99ms. Mas 10% dos usuários teve uma experiência horrível, e o painel está verde.

Percentil resolve isso. Você ordena todas as latências, da menor para a maior, e olha onde está cada corte.

Amplificação de cauda#

Agora a parte que muda o desenho da sua arquitetura.

Suponha que a sua página faça dez chamadas internas para montar a resposta, e cada serviço tenha p99 de 1 segundo. Qual a chance de a página inteira ficar lenta?

Não é 1%. É a chance de pelo menos uma das dez cair na cauda — aproximadamente 10%.

Isso se chama amplificação de cauda, e a consequência é dura: quanto mais você quebra o sistema em serviços, mais o p99 individual de cada um se transforma no p90 do usuário final.

Em arquitetura distribuída, o p99 dos componentes é um orçamento coletivo, não uma métrica individual. Cada serviço novo no caminho crítico consome parte desse orçamento.

O que fazer com a cauda#

As causas típicas, e vale caçar nessa ordem:

1. Pausa de GC — picos periódicos sem correlação com tráfego.
2. Disputa de lock — piora com concorrência, não melhora com mais CPU.
3. Cache frio — depois de deploy ou de expiração em massa.
4. Vizinho barulhento — outro processo na mesma máquina.
5. Retransmissão de TCP — perda de pacote; o TCP reduz a janela e a latência salta.
6. Fila — em qualquer ponto do caminho, e é a mais comum das seis.

E existe uma técnica direta contra a cauda, popularizada pelo Google, chamada hedging: se a requisição não responder até o p95, você dispara uma segunda para outra réplica e usa a primeira resposta que chegar. Você paga uns 5% de tráfego extra e corta a cauda de forma expressiva.

Como começar hoje#

Três medidas concretas, na ordem:

1. Substitua média por percentil em todos os painéis. Se o seu sistema de métricas só guarda média, ele está te escondendo o problema.
2. Meça p50, p95 e p99 por endpoint, não só o agregado do serviço. O agregado esconde o endpoint ruim atrás do endpoint popular e rápido.
3. Calcule as requisições em andamento com a Lei de Little e compare com o tamanho dos seus pools. Muito maior que o necessário significa disputa paga à toa; menor significa fila.

Feito isso, "o sistema está lento" deixa de ser opinião e vira uma frase com número, endpoint e percentil.

E aí dá para consertar.