Tail latency

Em fevereiro de 2013, Jeff Dean e Luiz André Barroso — ambos do Google — publicaram em Communications of the ACM um paper de oito páginas que mudou a forma como engenheiros de sistemas distribuídos pensam sobre latência. O título era The Tail at Scale, e o argumento central era contraintuitivo: à medida que um sistema escala para servir respostas a partir de muitos componentes paralelos, a cauda da distribuição de latência (P99 e além) deixa de ser um problema de borda e vira a métrica dominante. Em sistemas com fan-out alto, o P99 individual de cada componente pequeno se acumula até virar a mediana do usuário final.

A intuição é simples e devastadora. Imagine um servidor que tem P99 de 100 ms (1 em cada 100 requests demora 100 ms ou mais) e P50 de 10 ms (mediana). Se uma página precisa fazer fan-out a 100 servidores em paralelo, e espera todas as respostas para renderizar, a probabilidade de pelo menos uma das 100 cair na cauda é ~63% (1 - (1 - 0.01)^100). Em outras palavras: em 63% dos requests do usuário, alguma chamada paralela cai no P99. A latência percebida pelo usuário é dominada pela cauda, não pela mediana — exatamente o oposto do que a intuição sugere.

A consequência operacional é dura. Sistemas distribuídos modernos — busca, recomendação, feed, anúncios — tipicamente têm fan-out de dezenas a centenas de chamadas por request final. Otimizar P50 desses componentes individuais entrega ganho marginal; otimizar P99 (e P99.9) entrega ganho transformador. Esse é o ponto canônico de Dean & Barroso, e organizou pesquisa e prática de latência distribuída pela década seguinte. Hedged requests, tied requests, brief throttling — todas técnicas conhecidas hoje pegam a sua articulação madura nesse paper.

Este conceito articula o argumento, mostra a matemática do fan-out, enuncia as quatro técnicas canônicas para domesticar a cauda, e enuncia heurísticas de design para sistemas que vão escalar. O tema conecta com o conceito 03 (distribuição de latência) e antecipa o conceito 12 (performance testing), onde se mensura a cauda em sistemas reais.

A matemática do fan-out — por que P99 vence

Considere um sistema que executa n chamadas paralelas e espera todas. Se cada chamada tem probabilidade p de cair na "cauda lenta" (acima de algum threshold), a probabilidade de pelo menos uma cair na cauda é 1 - (1 - p)^n. Para p = 0.01 (P99 de cada chamada) e n = 100, isso vira ~63%. Para n = 1000, vira essencialmente 100%.

Reformulando: o P99 individual vira o P50 do agregado em torno de n = 70; vira o P10 do agregado em n = 230. Em sistemas com fan-out de centenas, a "cauda lenta" deixa de ser exceção e vira norma. Otimizar a cauda individual de cada serviço — fazer P99 cair de 100 ms para 10 ms — tem efeito multiplicativo no sistema agregado.

Há também o caso de fan-out parcial — onde a resposta agregada espera só os primeiros k retornos (busca que mostra os primeiros k resultados, por exemplo). Nessa configuração, a cauda agregada tipicamente melhora — você ignora o último a responder. Sistemas de busca aproveitam essa propriedade, definindo timeouts por shard que sacrificam completude por previsibilidade de latência.

De onde vem a cauda — fontes mensuráveis

A pergunta pragmática é "o que causa a cauda?". Dean & Barroso catalogaram, e a literatura complementou. A taxonomia das causas é parte do diagnóstico.

Compartilhamento de recursos. Em servidor multi-tenant, queries de outros usuários que rodam ao mesmo tempo causam contention em CPU, banco, I/O. Pequenos picos viram causa de spike de latência local.

Manutenção em background. Garbage collection (especialmente JVM clássica e .NET com pause), compaction de banco (especialmente LSM-tree), backup de snapshot, log rotation, atualização de configuração. Cada um introduz pausas curtas mas com latência alta enquanto duram. Conceito 08 do módulo detalha GC.

Filas e congestionamento. Buffer lotado, connection pool saturado, network bandwidth saturada. Pequenas flutuações em chegada de tráfego causam crescimento exponencial de fila perto do limite.

Daemon scheduling. Sistema operacional decide rodar daemon de manutenção (cron, monitoring, log shipper) e suspende sua aplicação por milissegundos. Em escala de microsserviços, isso vira sintoma frequente.

Falhas e retry. Operação que falhou e foi retentada acumula latência. Conceito 09 do módulo 05 (retry/timeout/circuit breaker) tratou o assunto.

Throttling térmico. Em hardware moderno, CPU em sobrecarga sustentada reduz frequência por proteção térmica. O sintoma é hot path que estava em 50 ms passar a 80 ms sob carga sustentada.

Power management agressivo. Em datacenter moderno, CPUs entram em estados de baixa frequência em ociosidade. Quando uma request chega depois de período ocioso, primeiros milissegundos rodam mais devagar até a CPU subir frequência. Latência ímpar em start.

As técnicas canônicas — domando a cauda

Dean & Barroso catalogaram quatro classes de técnicas que sistemas de produção usam para reduzir o impacto da cauda. Cada uma tem trade-off próprio, e a escolha apropriada depende do sistema.

Hedged requests

Você envia uma request para o servidor A. Se ela não retornou em até P95 esperado, envia uma segunda request para o servidor B (réplica). Aceita a primeira resposta que voltar; descarta a segunda. O custo é tráfego extra de ~5% (apenas as 5% que excederam P95 precisam do hedge); o benefício é que P99 percebido pelo cliente passa a ser P99 do melhor de duas tentativas — quase sempre baixo.

A matemática é elegante: se cada chamada tem P99 de 100 ms e elas são independentes, hedged request tem "P99 do melhor de 2" próximo de P95 da distribuição original (~50 ms). Você comprou redução de 2× na cauda ao custo de 5% mais tráfego.

Tied requests

Variante mais sofisticada de hedged. Você envia para A e B simultaneamente, mas com um link entre as duas requests: assim que uma começa a executar, ela cancela a outra. Custo de tráfego é o mesmo (duas requests entram), mas custo de execução é menor — só uma executa de fato. Era a técnica preferida pelo Google em sistemas internos com volume alto.

Brief throttling

Quando o servidor detecta que está sob estresse local (GC iminente, fila de requests subindo), ele recusa requests novas brevemente com erro retentável. O cliente, com retry policy adequado, vai para outra réplica. O resultado é que requests que chegariam num servidor degradado são desviadas preventivamente.

Selective replication

Réplicas adicionais para subconjuntos de tráfego mais sensíveis a cauda. Em busca, queries que afetam UI crítica (top results) podem rodar em mais réplicas que queries de relevância secundária.

SLO baseado em P99 — articulação canônica

A consequência prática para SRE é que SLO de latência em sistemas modernos sempre se articula em percentis — não em média. A formulação canônica é:

SLO: 99% das requests < 200 ms, medido em janela de 30 dias
Error budget: 1% × tráfego mensal
Alerta: P99 > 200 ms por 5 minutos consecutivos
Page: P99 > 500 ms por 2 minutos consecutivos

O percentil define a granularidade de "request lenta"; o threshold define o que é "aceitável"; o error budget define quanto pode falhar em um mês. Sistemas que atingem SLO consistentemente operam dentro do budget; sistemas que estouram entram em modo de "freeze de mudanças" até voltarem a respeitar.

Em sistemas com fan-out alto, é comum SLO em P99.9 — não em P99 — exatamente porque P99 vira mediana do agregado. A operação fica "P99.9 < 1s", mais agressivo do que parece. Sêniores que entram em times de SRE precisam saber articular esse nível de granularidade.

Hedged request implementado

A implementação de hedged request mostra o padrão. Em qualquer linguagem, é "dispara segunda request após timeout, aceita a primeira que vier, cancela a outra".

public async Task<TResult> HedgedAsync<TResult>(
    Func<CancellationToken, Task<TResult>> primary,
    Func<CancellationToken, Task<TResult>> secondary,
    TimeSpan hedgeAfter,
    CancellationToken ct)
{
    using var cts = CancellationTokenSource.CreateLinkedTokenSource(ct);

    var primaryTask = primary(cts.Token);

    // espera primary OR hedgeAfter
    var winner = await Task.WhenAny(primaryTask, Task.Delay(hedgeAfter, cts.Token));
    if (winner == primaryTask)
    {
        return await primaryTask;
    }

    // primary demorou; dispara secondary em paralelo
    var secondaryTask = secondary(cts.Token);
    var first = await Task.WhenAny(primaryTask, secondaryTask);
    cts.Cancel();                 // cancela a outra
    return await first;
}

// uso
var resultado = await HedgedAsync(
    ct => ChamarRéplicaA(req, ct),
    ct => ChamarRéplicaB(req, ct),
    hedgeAfter: TimeSpan.FromMilliseconds(50),  // P95 esperado
    ct);

import asyncio
from typing import Awaitable, Callable, TypeVar

T = TypeVar("T")

async def hedged(
    primary: Callable[[], Awaitable[T]],
    secondary: Callable[[], Awaitable[T]],
    hedge_after: float,
) -> T:
    p_task = asyncio.create_task(primary())
    try:
        # espera primary completar OR timeout
        return await asyncio.wait_for(asyncio.shield(p_task), hedge_after)
    except asyncio.TimeoutError:
        pass

    # primary demorou; dispara secondary em paralelo
    s_task = asyncio.create_task(secondary())
    done, pending = await asyncio.wait(
        {p_task, s_task},
        return_when=asyncio.FIRST_COMPLETED,
    )
    for t in pending:
        t.cancel()
    return done.pop().result()

# uso
resultado = await hedged(
    primary=lambda: chamar_replica_a(req),
    secondary=lambda: chamar_replica_b(req),
    hedge_after=0.05,                       # P95 esperado em segundos
)

func Hedged[T any](
    ctx context.Context,
    primary, secondary func(context.Context) (T, error),
    hedgeAfter time.Duration,
) (T, error) {
    ctx, cancel := context.WithCancel(ctx)
    defer cancel()

    type result struct { v T; err error }
    primaryCh := make(chan result, 1)
    secondaryCh := make(chan result, 1)

    go func() {
        v, err := primary(ctx)
        primaryCh <- result{v, err}
    }()

    timer := time.NewTimer(hedgeAfter)
    defer timer.Stop()

    select {
    case r := <-primaryCh:
        return r.v, r.err
    case <-timer.C:
        // primary demorou; lança secondary
        go func() {
            v, err := secondary(ctx)
            secondaryCh <- result{v, err}
        }()
        select {
        case r := <-primaryCh: return r.v, r.err
        case r := <-secondaryCh: return r.v, r.err
        case <-ctx.Done(): var zero T; return zero, ctx.Err()
        }
    case <-ctx.Done():
        var zero T; return zero, ctx.Err()
    }
}

// uso
resultado, err := Hedged(ctx,
    func(c context.Context) (Result, error) { return chamarReplicaA(c, req) },
    func(c context.Context) (Result, error) { return chamarReplicaB(c, req) },
    50*time.Millisecond,
)

Quando NÃO aplicar hedged request

Hedged request é poderosa em chamadas idempotentes e baratas individualmente. Há casos onde aplicar é prejuízo.

Operações não-idempotentes. Se a "segunda" request pode efetuar a operação enquanto a primeira ainda está executando, você pode duplicar escrita — pedido cobrado duas vezes, e-mail enviado duas vezes. Hedged request em POST /pedidos sem idempotency key é desastre. Conceito 09 do módulo 05 cobriu o tema.

Operações caras. Se uma request consome bastante CPU/banco, dobrar o tráfego para reduzir cauda pode saturar o sistema todo. Você pagou cauda menor com degradação geral. Hedged só vale para operações tipicamente baratas.

Sistema sob estresse generalizado. Se todos os servidores estão lentos (não é só uma replica degradada), hedge não ajuda — as duas réplicas provavelmente estão na cauda também. E você só piorou, adicionando carga.

Diagnóstico de cauda — onde olhar

Identificar a fonte da cauda é trabalho de senior. A ferramenta primária é o histograma de latência (conceito 03), preferencialmente com etiquetas por causa potencial. Em ferramentas modernas (Prometheus, OTel), você quebra a métrica de latência por endpoint, cache_status, db_query_type, e plota cada subsetting. Quando uma das classes domina a cauda, você localizou a causa.

A ferramenta secundária é tracing distribuído (conceito 08 do módulo 05). Cada request slow vira trace individual; navegando para os spans, você vê onde o tempo foi gasto. Em sistemas modernos com OTel exemplars, a métrica histogram aponta diretamente para um trace específico que produziu aquele bucket.

A ferramenta terciária é continuous profiling (conceito 05 deste módulo). Quando a causa é GC, lock contention, ou hot path inesperado, profiles capturados durante incidente revelam o sintoma diretamente.

Latência cumulativa — sessões e jornadas

Em sistemas que atendem usuários humanos, raramente uma única request define a experiência. O usuário interage — navega, clica, abre, fecha — em uma sessão. Cada request individual é uma amostra da distribuição; a probabilidade de o usuário tocar a cauda em algum ponto da sessão depende do número de requests.

Se cada request tem P99 de 1s, e o usuário faz 50 requests numa sessão, a probabilidade de ele experienciar pelo menos uma request lenta é ~40% (1 - 0.99^50). Para usuários power (que fazem centenas de requests), a probabilidade vira essencialmente 100%. P99 individual virou "experiência regular" em escala de sessão.

A consequência: SLO de latência precisa ser ainda mais agressivo que parece quando aplicado por sessão. Sistemas que sustentam UX boa em sessões longas operam P99 em faixas que parecem exageradas para request individual — P99 de 200 ms para sessões de 100 requests dá ~18% de probabilidade de cauda; P99 de 100 ms dá ~10%; P99 de 50 ms dá ~5%. Cada ordem de magnitude de melhora em P99 tem efeito linear em "fração de usuários frustrados".

Por que importa para a sua carreira

Tail latency é tópico onde sêniores se distinguem claramente. Em entrevistas para sistemas distribuídos (Google, Meta, Stripe, qualquer empresa com escala grande), perguntar "como você reduziria a P99 desse sistema?" é convite direto para mostrar conhecimento de Dean & Barroso, hedged requests, fan-out math. Em revisão de design, articular "esse sistema tem fan-out de 50 — então P99 de cada um vira P40 do usuário" muda o padrão da conversa. Em pos-mortem de "sistema lentou", localizar a causa via histograma tagueado e tracing distribuído é trabalho de senior. E em definições de SLO com produto, traduzir "boa experiência" em "P99.9 < X ms em sessão de Y requests" cria base mensurável e defensável.

Como praticar

1. Simulação de fan-out. Implemente um cliente que faz N chamadas paralelas a um servidor com latência simulada (incluindo cauda). Plote a latência agregada (esperar todas) versus N. Repita para diferentes valores do P99 individual. Você vai ver a curva inclinar — para N grande, latência agregada cresce mesmo se P99 individual é baixo. Esse exercício torna a matemática do paper viva.
2. Hedged request num projeto seu. Identifique uma chamada externa idempotente que tem cauda significativa (P99 muito acima de P50). Implemente hedged request com timeout em P95. Meça antes e depois — P99 do cliente, taxa de tráfego extra. Documente trade-off observado. Esse é o tipo de mudança que tipicamente reduz cauda em 2-5×.
3. Auditoria de SLO. Pegue os SLOs do seu projeto (se não houver, é o trabalho — escrever). Para cada um, articule: é em qual percentil? É no nível de request individual ou de sessão? Tem fan-out considerado? Identifique pelo menos um SLO que está articulado de forma fraca (média em vez de percentil, ou P95 quando deveria ser P99 por causa do fan-out) e proponha refinamento. Esse é o trabalho de senior em SRE.