Plataforma · Performance

Latência é orçamento, não sorte.

Cada milissegundo é negociado antes do código existir. Hot paths sem alocações, p99 monitorado em tempo real, throughput previsível sob 10× a carga típica — performance é decisão de arquitetura, não otimização tardia. Medimos, orçamentamos e auditamos cada hop entre o cliente e o banco.

LIVE · System latency p99 RANGE · 0–300ms
42ms
P99 · END-TO-END
EDGE
9ms
SERVICES
21ms
DATA
12ms
01 · Pilares de performance

Latência, throughput,
footprint, custo.

Performance não é um número — são quatro dimensões em tensão constante. Otimizar uma sem tocar nas outras é folclore. Cada decisão de arquitetura é avaliada contra os quatro pilares antes de virar código.

Latência

Quanto tempo até a resposta

P50 conta uma história, p99 conta a verdade. Otimizamos a cauda — onde mora o cliente irritado, o timeout em cascata e a perda de receita.

  • P50 · P95 · P99 · P99.9
  • Orçamento por hop
  • Tail-tolerant retries
Throughput

Quantas requests por segundo

RPS sustentado sob pico, não em benchmark de papel. Carga real, dados reais, falhas injetadas — capacidade só vale se aguentar Black Friday.

  • RPS por endpoint · por core
  • Saturação antes do colapso
  • Backpressure declarativo
Footprint

Quanto custa em recurso

Memória, CPU, GC, allocations por request. Hot paths sem alocação não são vaidade — são o que mantém o p99 estável quando o cluster aperta.

  • Allocations · GC pauses
  • Span<T> · ArrayPool
  • Native AOT onde cabe
Custo

Quanto por mil chamadas

Performance sem orçamento de cloud é miragem. Custo por request, por tenant, por feature — auditado release a release.

  • $ por milhão de requests
  • FinOps no CI
  • Right-size automático
02 · Camadas de medição

Onde medir
antes de otimizar.

Otimizar sem medir é ficção. Cada camada da stack tem seu instrumento, seu indicador e seu limiar de alerta — sem isso, "rápido" é opinião.

Camada
O que medimos
Indicador-chave
Ferramentas
Cliente
Web · Mobile
Core Web Vitals em produção, INP, jank em scroll, frame budget mobile, tempo até primeiro byte interativo.
Web VitalsLighthouse CISentry RUM
Edge
CDN · Gateway
TTFB por região, hit-ratio de cache, latência de TLS handshake, fila de conexões na borda.
Cloudflare AnalyticsEnvoy statsYARP metrics
Aplicação
.NET · workers
Allocations por request, GC pauses, ThreadPool starvation, contention de locks, hot path em ETW.
BenchmarkDotNetdotnet-countersPerfViewJetBrains dotTrace
Plataforma
K8s · runtime
CPU throttling, memory pressure, OOMKills, pod startup, latência de scheduling, custo por namespace.
kube-state-metricsnode-exporterOpenCost
Dados
DB · cache · bus
Slow-query log, plano de execução, lag de réplica, hit-ratio de cache, profundidade de fila, dead-letter.
pg_stat_statementspgbadgerRedisInsightBurrow
Carga
Testes de stress
RPS sustentado, ponto de saturação, latência sob 2× e 5× o pico, recuperação após overload, soak de 24h.
NBomberk6LocustJMeter
03 · Orçamento de latência

Cada hop tem
seu teto.

Latência ponta-a-ponta é soma de hops. Definimos o orçamento por etapa antes da feature existir — quando uma camada estoura, o alerta sai antes do usuário notar.

Cliente · TLS
12 ms
CDN · Edge
9 ms
API Gateway
7 ms
Auth · OIDC
16 ms
BFF · App
21 ms
Cache · DB
24 ms
Serialização
10 ms
Render · client
19 ms
Orçamento p99 fim a fim
≤ 250ms
Meta padrão para APIs transacionais; jornadas críticas operam sob 120ms.
Burn-rate alerta
14m
Alerta dispara quando o budget mensal é consumido 2× mais rápido que o esperado em janela curta.
Detecção
< 60s
Tempo médio entre o evento real e o alerta acionado — anomalia detectada no agregado de 1 minuto.
04 · Perfis de carga

Capacidade
auditada em contrato.

Cada serviço entra em produção com seu envelope de capacidade documentado: pico esperado, ponto de saturação medido, comportamento sob stress. Não há surpresa de Black Friday — há ensaio.

Perfil
RPS sustentado
P99 sob carga
Saturação medida
Comportamento em pico
Steady · Baseline Operação típica Carga média de produção em janela útil — o que paga as contas.
1.2kpor core · sustentado
≤ 80msorçamento · 250ms
35%CPU média
linearsem fila
Spike · 3× Pico anunciado Campanha, lançamento, evento sazonal — três vezes a carga típica por horas.
3.6k3× sustentado
≤ 180msdegradação aceita
68%HPA acionado
elásticoscale-out 2min
Surge · 5× Pico inesperado Viralização, falha em sistema vizinho, hotspot regional — cinco vezes em segundos.
6k5× sustentado
≤ 320msSLO em risco
85%backpressure
shed gracioso503 controlado
Overload · 10× Ataque ou cascata DDoS, bug em cliente, retry storm — dez vezes a carga típica em minutos.
12klimitado por gateway
≤ 500mssó essencial
95%circuit breaker
fail-fastrate-limit ativo
05 · Técnicas de otimização

Onde os ms
realmente moram.

Otimização não é arte negra — é repertório. Seis técnicas aplicadas onde cada uma rende mais. Aplicadas no lugar errado, custam complexidade sem ganho; no lugar certo, devolvem dezenas de milissegundos.

01 · Hot path

Zero allocations

Span<T>, ArrayPool, ValueTask e pooled buffers eliminam GC sob pico. Parsing, serialização e crypto sem heap.

−40% GC pauses
02 · Concurrency

Async tudo, locks zero

Channels, lock-free counters, immutable snapshots. Contention some quando o estado compartilhado some.

2× throughput
03 · Cache

Onde o dado quer estar

L1 in-process, L2 Redis, CDN na borda. Invalidação por evento, não por TTL otimista. Hit-ratio é métrica de release.

≥ 92% hit
04 · Database

Plano antes de query

EXPLAIN é code review. Índices auditados, N+1 banido em CI, particionamento explícito, conexão poolada com timeout curto.

p99 −60ms
05 · Network

Menos hops, menos bytes

HTTP/2 multiplexado, gRPC com protobuf interno, compressão Brotli, keep-alive longo, DNS pré-resolvido.

−30% TTFB
06 · Compile

Code-gen e AOT

Source generators eliminam reflection, Native AOT entrega cold-start < 100ms, SIMD vetoriza loops numéricos.

cold < 100ms
06 · Disciplina de benchmark

Medir é parte
do código.

Benchmark sem disciplina vira teatro. Três práticas obrigatórias para que cada commit defenda o que afirma sobre desempenho — antes de prometer, comprovamos.

Microbench em CI

BenchmarkDotNet · regressão bloqueia merge

Hot paths críticos têm benchmark versionado em git. Cada PR roda a suíte; piora > 5% em allocations ou tempo médio reprova automaticamente. Comparações com baseline assinada por release.

Coberturaparsers, serializers, hot DTOs
Threshold+5% tempo · +10% allocations
Históricotrend visível em dashboard

Load test em staging

NBomber · k6 · perfis reais

Antes de cada release de impacto, perfil de carga simulando 1×, 3× e 5× a produção. Dados anonimizados de prod, falhas injetadas (network, DB, dependência), 24h de soak quando aplicável.

Fidelidadeprod-shaped data · chaos injection
Critériosp99 dentro do envelope publicado
Soak24h sem leak · sem drift

Profiling em produção

contínuo · amostral · seguro

Profiler sempre ligado em amostragem leve. Flame graphs continuamente disponíveis, hotspots identificados antes de virarem incidente. Auditoria em mãos quando a otimização precisar de evidência.

FerramentaPyroscope · dotnet-trace · Parca
Custo< 2% CPU overhead
Retenção14 dias · diff entre releases
07 · Indicadores agregados

Os números que
defendemos.

Médias agregadas da operação TecLimit nos últimos 12 meses, em projetos sob SLA de performance. Ilustrativos por fluxo crítico — cada cliente recebe seu painel real em onboarding.

P99 médio
142ms
↓ 18ms
Latência fim a fim · 90 dias · APIs transacionais
RPS por core
1.4k
↑ 220
Throughput sustentado · workloads transacionais .NET
Allocations
2.8kb/req
↓ 41%
Heap por request · hot paths após otimização
Custo
$0.18/Mreq
↓ 27%
Custo médio por milhão de requests · cloud público
"Performance é orçamento que se honra. Não é o que medimos no benchmark — é o que o usuário sente no p99."
— Posicionamento técnico TecLimit

Sua plataforma merece latência negociada.

Conte-nos sobre seus serviços críticos, picos esperados e gargalos atuais. Em uma conversa devolvemos um plano de medição e otimização concreto.