Come scalare i singoli servizi e trovare i colli di bottiglia delle prestazioni?

Question

Accepted Answer

Un vantaggio chiave dei microservizi è **scalare ogni servizio indipendentemente** per adattarsi al proprio carico, invece di scalare l'intera app. Trovare i colli di bottiglia è quindi una questione di misurazione per-servizio e per-hop.

## Tecniche di scaling

- **Horizontal scaling** — aggiungi istanze stateless dietro un load balancer.
- **Autoscaling** — scala su CPU, memoria, profondità della coda o metriche personalizzate.
- **Caching** — riduci il lavoro ripetuto e il carico downstream.
- **Async + queues** — assorbi i picchi; disaccoppia il lavoro lento.
- **Data scaling** — read replicas, sharding, store per-servizio.

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

## Trovare i colli di bottiglia

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

## Colli di bottiglia comuni

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

## Insidia

Scalare un servizio il cui collo di bottiglia è un **database condiviso** sposta semplicemente più carico sul DB — scala il vincolo reale, non il sintomo.

## Perché è importante

Lo scaling indipendente ti consente di spendere capacità precisamente dove si trova il carico, il che è molto più economico che scalare un monolite nel suo insieme.

Ma scalare alla cieca spreca denaro e può peggiorare le cose; misurare le metriche per-servizio e le tracce per-hop è ciò che ti dice il vero vincolo da risolvere.