Como você escala serviços individuais e encontra gargalos de desempenho?

Question

Accepted Answer

Um benefício chave dos microsserviços é **escalar cada serviço independentemente** para corresponder a sua própria carga, em vez de escalar toda a aplicação. Encontrar gargalos é então uma questão de medir por serviço e por salto.

## Técnicas de escalabilidade

- **Escalabilidade horizontal** — adicionar instâncias sem estado atrás de um balanceador de carga.
- **Autoescalabilidade** — escalar em CPU, memória, profundidade de fila ou métricas customizadas.
- **Cache** — reduzir trabalho repetido e carga downstream.
- **Async + filas** — absorver picos; desacoplar trabalho lento.
- **Escalabilidade de dados** — réplicas de leitura, sharding, armazenamentos por serviço.

```yaml
# Kubernetes HPA: scale orders on CPU
minReplicas: 3
maxReplicas: 20
metric: cpu
targetUtilization: 70   # add pods when avg CPU > 70%
```

## Encontrando gargalos

```text
1. Metrics: which service has high latency / saturation? (RED/USE)
2. Traces: which SPAN in the request is slow?
3. Drill in: DB query? lock? N+1 calls? GC pause?
```

```text
Gateway ──┤ Orders ──┤ Payments ████████████ ← 80% of latency here
                       Inventory ─┤
```

## Gargalos comuns

```text
⚠️ Chatty synchronous calls (fan-out per request)
⚠️ Shared/overloaded database
⚠️ Missing or cold cache
⚠️ Unbounded retries amplifying load
```

## Armadilha

Escalar um serviço cujo gargalo é um **banco de dados compartilhado** apenas move mais carga para o BD — escale a restrição real, não o sintoma.

## Por que isso importa

A escalabilidade independente permite que você gaste capacidade precisamente onde a carga está, o que é muito mais barato do que escalar um monólito em massa.

Mas escalar às cegas desperdiça dinheiro e pode piorar as coisas; medir métricas por serviço e rastrear por salto é o que lhe diz qual é a restrição real a corrigir.