Arquitetura de baixo atraso

Por que precisa de uma arquitetura de baixo atraso

O atraso baixo não é apenas uma média rápida, mas uma cauda estável (p95/p99) com carga real. O caminho para isso é o orçamento de atraso, disciplina de filas/retrações, proximidade de dados e de dinheiro, protocolos/conectórios corretos e operação rigorosa (limites, observabilidade, degradação).

Metas e orçamento de atraso

1. Defina o SLO: "p95 ≤ 120 ms, p99 ≤ 250 ms, erro ≤ 0. 3%».
2. Colecione o orçamento: o cliente edge para a região serviços estores resposta.

• Cliente-edge: 15 ms
• Região Edge: 15 ms
• Gateway/L7: 10 ms
• Serviço de negócios: 40 ms
• Armazenamento/dinheiro: 25 ms
• Reserva/jitter: 15 ms

Métricas e colas

Mede p50/p90/p95/p99, passa e em cada hop.
Divida por editoras: região, método, versão do cliente, tipo de rede (mobile/broadband), tamanho payload.
Discrepar entre o tempo de fila e o tempo de execução (consulte Little's Law: L = £ W).
Técnicas sensíveis a tail: hedged requests (raramente e com proteção), proibição de retrações em cascata.

Rede e protocolos

QUIC/HTTP/3: menos perdas de celular/roaming, multiplexagem sem head-of-line.
TLS 1. 3 e 0-PTT (somente para consultas idumpotentes seguras).
DNS: TTL curto para rotas dinâmicas, Anycast para POP.
TCP: 'TCP _ NODELAY' (cuidadosamente), desativar os demais 'Nagle '/' Delayed ACK' onde for justificado; keep-alive e restauração rápida de conexões.
gRPC/HTTP/2: multiplex, flow-controle e configurações de janelas; evite compressão excessiva em pequenos payload.

Conexões e podos

Divida as pulas por domínios/destino (para evitar que os «vizinhos lentos» tirem slots).
Warm-up/Keep-alive: mantenha o número sustentável de conectórios quentes.
Connection coalescing (HTTP/2/3) и reuse.
«Connect», «TLS handshake», «request», «idle». Diferentes significados em diferentes hopes.

Local de dados e cálculos

Edge/região: Leve leituras e cálculos fáceis para perto do usuário (consulte Edge-nó e lógica regional).
Read-local/Write-global: réplicas para leitura, verdade global para gravação.
Hierarquia em dinheiro: CDN/edge-dinheiro → KV/Redis regional → armazenamento de serviço → in-pro local.
Aquecimento (warming): carregando chaves quentes durante o lançamento/zoom.
Stale-while-revalidate para dados de baixa capacidade.

Armazenamento e índices

Selecione os esquemas de acesso O (1 )/O (logN); mantenha os índices apertados sob consultas frequentes.
Hot-keys: curte por 'hash (id)' ou adicione 'sal' para ser uniforme.
Batching na saída para BD/kesh (até tamanho razoável) em vez de dezenas de chamadas individuais.
Para o OLTP, transações o mais curtas possível; read-committed/snapshot em vez de bloqueios em série.

Competição e técnicas sem bloqueio

Primeiro, resolva as expectativas nas filas e depois otimize o CPU.
Async I/O e controladores não bloqueadores; estruturas lock-free onde for apropriado.
Evite os mutex globais; loki de grande porte, CAS/versioning.
Poulas de fluxo: fixe as dimensões para não entrar em contextos-pergaminho.
Consciência NUMA - Alocação de fluxo a soquetes, alocadores locais.

JVM/GC e sintonização Rantaim (se aplicável)

Geração de código e alocação: menos efeitos laterais → menos pausas GC.
Coletores modernos (G1/ZGC/Shenandoah) com pausas de destino; escapes e aluguel de buffers.
Class/Data sharing, JIT warming, AOT/native-imagem para funções dependentes iniciais.
Histogramas de pausas GC incluam no orçamento total de atraso.

Filas, backpressure, proteção contra sobrecarga

Tamanho da fila = pequena: longas filas dão «p50 bonito» e matam p99.
Backpressure explícito: responda mais devagar do que copiar.
Adaptative concurrency: reduza a paralelidade com o aumento de erros/latência (algoritmos VEGAS/gradiente, AIMD).
Circuito breaker: falhas rápidas para degradação de upstream, bolkhead (empresas de camarotes) para pool e recursos.
Rate limit: janela deslizante/tokens, priorização (user tier/critical-path).

Retraias, hejing e idumpotência

Retrai apenas para erros transitivos, com o jitter e o máximo de tentativas.
Operações Idempotentes e 'Idempotency-Key' são obrigatórias para repetições.
Hedged requests: Envie as duplicações após a liminar (por exemplo, p95 + 10 ms) e cancele sempre a mais.
Nunca retraia dentro de cada camada sem coordenação - receba uma tempestade.

Armazenamento em dinheiro e aquecimento

O caminho quente deve ficar sem rede com carga de trabalho típica (in-tech/LRU).
Negative cache em 10-60 c para não bater as chaves que faltam.
Aquecimento em massa no lançamento/skeiling - listas de chaves quentes, read-ahead, background refresh.

Degradação e folbeques

Graceful Degradation: Corte de fichas secundárias ao aumentar a latência (resposta menos detalhada, desativação de enriquecimento).
Soft timeouts: devolva a resposta básica/kesh em vez de 5xx.
Fail-open/Fail-closed - Documente claramente para cada chamada.

Observabilidade e perfilagem

Trailing de distribuição: spans em cada hop, sampling de caudas (tail-based).
RED/USE метрики: Rate, Errors, Duration / Utilization, Saturation, Errors.
Top-N rotas «lentas» diariamente.
Perfiladores (alloc/cpu/lock) em venda com overhead baixo (eBPF/async-profiler/Flight Recorder).
Sintéticos de diferentes ASN/redes e canais móveis.

Testes de desempenho

Testes Latency-SLO (p95/p99) com payload real e variabilidade.
Cenários chaos: degradação DNS, aumento da perda de pacotes, atrasos TLS, estor «lento».
Cold-start/scale-up: Mede os primeiros minutos após o lançamento quando os cachês estiverem vazios.
Divida as balas de carga em cenários (não atrapalhe os testes de read/write).

Mini-modelos

Política de timeouts/retrações (pseudo)

yaml timeouts:
connect: 100ms tls_handshake: 150ms request_p95_budget: 80ms retries:
max_attempts: 2 backoff: exp_jitter(10ms..60ms)
retry_on: [CONNECT_ERROR, TIMEOUT, 502, 503, 504]
hedging:
enabled: true threshold: p95 + 10ms cancel_extra_on_first_success: true circuit_breaker:
error_rate_threshold: 5%
p95_threshold_increase: 30%
half_open_after: 10s

Pulas e bulkhead's

yaml pools:
checkout:
max_conns: 256 per_host: 64 queue: 8 # small analytics queue:
max_conns: 64 queue: 4

Resposta com degradação

json
{
"status": "ok",
"profile": { "id": "u123", "name": "…"},
"recommendations": "degraded, "//disabled the heavy part
"served_from": "edge-cache",
"trace_id": "…"
}

Malas de aplicação

iGaming/finanças: permissão de pagamento <200 ms p95, limite/balanço - leitura a partir de projeções regionais, e entradas idumpotentes com a versão.
Marketing/recomendações: respostas <100 ms p95, dinheiro fich-bandeiras em edge, modelos de mapeamento preliminar + regras rápidas no caminho quente.
Clientes móveis HTTP/3, reuse agressivo de conectórios, payload reduzido (Protobuf), temporizadores de proteção e dinheiro offline.

Anti-pattern

Longas filas em frente aos workers, «bela média» e p99 morto.
Retraias em cascata em cada camada sem coordenação.
Mega-dinheiro global sem deficiência ou aquecimento.
Os horários vagos (por omissão) são caudas incontroláveis.
Um pool comum de conectórios para todo o tráfego é um bloqueio de head-of-line.
Lógica pesada em edge com efeitos estateful.
Telemetria desligada de cauda - você não vê p99.

Folha de cheque da produção

• Há um orçamento de atraso para os hops e os temporizadores por baixo.
• Estão incluídos HTTP/2/3, TLS 1. 3, balas de conectórios e warm-up.
• Hierarquia em dinheiro, lista de chaves quentes e estratégias de aquecimento.
• Read-local/Write-global e chaves quentes.
• backpressure explícito, pequenas filas, circuito-breakers e bulkhead's.
• Retrai com jitter, idumpotência, hejing limitado.
• Tracing com marcas de região/versão/cliente; monitoramento p95/p99.
• Testes perf com sintéticos ASN/mobil, cenários cold-start e chaos.
• Os procedimentos de degradação e os folbacks foram documentados.
• p95/p99 correspondem a SLO na carga real.

FAQ

Porque é que o p99 é mais importante do que a média?
Porque os usuários enfrentam as caudas, não a média. O p99 mostra «quanto dói».

Devemos ligar o hedging para todo o lado?
Não. Ele é útil para caudas raras em caminhos críticos e apenas em limites rigorosos/idempotidade.

Como reduzir a partida fria?
Aquecimento de dinheiro/conexões, compilação prévia/aquecimento JIT, minimização de inicializações lazy, pool warm.

Podemos «vencer a rede»?
Em parte: HTTP/3, edge-POP, Anycast, payload compacto, conexion reuse e timeouts razoáveis.

Resultado

A arquitetura de baixo atraso é um sistema de acordo e disciplina: orçamento de atraso, proximidade de dados, pequenas filas, previsíveis retais, hierarquia do dinheiro, protocolos corretos e observação implacável de caudas. Seguindo estes princípios, você está mantendo p95/p99 sem sacrifícios de estabilidade e carteira.