¿Cómo escalas servicios individuales y encuentras cuellos de botella de rendimiento?

Question

Accepted Answer

Un beneficio clave de los microservicios es **escalar cada servicio de forma independiente** para coincidir con su propia carga, en lugar de escalar toda la aplicación. Encontrar cuellos de botella es entonces una cuestión de medir por servicio y por salto.

## Técnicas de escalado

- **Escalado horizontal** — agregar instancias sin estado detrás de un balanceador de carga.
- **Escalado automático** — escalar según CPU, memoria, profundidad de cola o métricas personalizadas.
- **Almacenamiento en caché** — reducir trabajo repetido y carga descendente.
- **Async + colas** — absorber picos; desacoplar trabajo lento.
- **Escalado de datos** — réplicas de lectura, sharding, almacenes por servicio.

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

## Encontrar cuellos de botella

```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 ─┤
```

## Cuellos de botella comunes

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

## Trampa

Escalar un servicio cuyo cuello de botella es una **base de datos compartida** simplemente traslada más carga a la BD — escala la restricción real, no el síntoma.

## Por qué es importante

El escalado independiente te permite gastar capacidad precisamente donde está la carga, lo cual es mucho más barato que escalar un monolito de forma generalizada.

Pero el escalado ciego desperdicia dinero y puede empeorar las cosas; medir métricas por servicio e trazas por salto es lo que te dice la restricción real que hay que corregir.