Hoe schaal je individuele services en hoe vind je performance bottlenecks?

Question

Accepted Answer

Een belangrijk voordeel van microservices is **elke service onafhankelijk schalen** om zijn eigen belasting aan te kunnen, in plaats van de hele applicatie te schalen. Het vinden van bottlenecks is dan een kwestie van meten per service en per hop.

## Schalingstechnieken

- **Horizontaal schalen** — stateless instances achter een load balancer toevoegen.
- **Autoscaling** — schalen op CPU, geheugen, queue depth of aangepaste metrics.
- **Caching** — herhaald werk en downstream belasting verminderen.
- **Async + queues** — pieken opvangen; langzaam werk ontkoppelen.
- **Data schaling** — read replicas, sharding, per-service stores.

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

## Bottlenecks vinden

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

## Veelvoorkomende bottlenecks

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

## Valkuil

Een service schalen waarvan de bottleneck een **gedeelde database** is, verplaatst alleen meer belasting naar de DB — schaal de werkelijke beperking, niet het symptoom.

## Waarom het belangrijk is

Onafhankelijk schalen laat je capaciteit precies waar de belasting is besteden, wat veel goedkoper is dan een monoliet wholesale te schalen.

Maar blind schalen verspilt geld en kan dingen erger maken; het meten van per-service metrics en per-hop traces vertelt je wat de werkelijke beperking is die je moet oplossen.