A p99 latency de uma API é de 3s — como faz debug e a otimiza?

Question

IT Interview Practice · Accepted Answer

p99 = **tail latency**: os 1% de pedidos mais lentos demoram 3s. O primeiro passo é **medir e decompor, não adivinhar**. Compare p50 vs p99 — se a p50 é rápida mas a p99 é 3s, o caminho não é uniformemente lento; algo morde apenas *sob carga ou em casos extremos* (saturação do pool, pausas de GC, N+1, cache fria, uma chamada externa sem timing).

**Modelo mental:** a p99 é a *fila de checkout mais longa*, não a espera média — acelerar a média não faz nada pelo cliente preso lá atrás.

## O processo (de onde para onde)
1. **Medir & decompor** — métricas RED (Rate, Errors, Duration) + distributed tracing; ler p50/p95/p99. O *intervalo* entre elas conta a história.
2. **Localizar a etapa** — instrumente cada passo para ver onde os pedidos lentos gastam tempo; não otimize por palpite.

```js
// Cronometra cada etapa para ver onde a p99 se acumula (não adivinhes)
async function handler(req, res) {
  const t0 = process.hrtime.bigint();
  const mark = (label) =>
    req.log.info({ label, ms: Number(process.hrtime.bigint() - t0) / 1e6 });
  const user = await db.user.find(req.id);   mark('db.user');
  const courses = await loadCourses(user);   mark('loadCourses'); // suspeito
  res.json(courses);                         mark('total');
}
```

3. **Identificar o suspeito da cauda** — normalmente *esperar*, não computar: esgotamento do connection pool, N+1 queries, chamadas externas sem timing, pausas de GC, índice em falta, cache fria.

```js
// ANTES: N+1 — N round-trips sequenciais, a p99 dispara à medida que N cresce
const courses = await db.course.findByUser(userId);
for (const c of courses) c.lessons = await db.lesson.byCourse(c.id);

// DEPOIS: colapsa para 1 query -> a cauda cai (sem mais N viagens sequenciais)
const courses = await db.course.findByUser(userId);
const lessons = await db.lesson.byCourseIds(courses.map((c) => c.id)); // um único IN(...)
const byCourse = Map.groupBy(lessons, (l) => l.courseId);
for (const c of courses) c.lessons = byCourse.get(c.id) ?? [];
```

Aqui a p50 (N pequeno) parece boa, mas sob carga o N cresce e o pool satura, portanto a **p99 detona**. Para chamadas externas, defina sempre um **timeout + circuit breaker** para que uma dependência lenta não possa arrastar a p99 de todo o endpoint.

4. **Corrigir uma coisa → medir de novo a p99 → repetir.** Uma variável de cada vez, ou não saberá o que ajudou.
5. **Consolidar** — defina um **SLO** (ex.: p99 < 300ms) + alerta para não regredir.

## Perspetiva de entrevista
O entrevistador está a testar um processo *metódico*, não um palpite com sorte: distingue **cauda de média**, mede antes de mudar e olha para **filas/locks (esperar) antes de CPU**. Resposta fraca: "adicionar caching / escalar os servidores." Resposta forte: medir → localizar com tracing → corrigir a causa específica da cauda → verificar com números.

## Princípio
Otimize a **cauda (p99), não a média**. A maioria dos "3s de p99" vem de *esperar* (pool/fila/lock) e não de *computar* — por isso olhe para as filas antes do CPU.

O processo (de onde para onde)

Perspetiva de entrevista

Princípio

Perguntas relacionadas