Hoe schat je schaal in en voer je capaciteitsplanning uit?

Question

Accepted Answer

**Schattingen en capaciteitsplanning** — het berekenen van verwachte belasting, gegevensvolume en resourcebehoeften — is een belangrijk onderdeel van systeemontwerp. Ruwe "back-of-the-envelope"-berekeningen informeren ontwerpbeslissingen (hoeveel je moet schalen, welke resources nodig zijn) en komen veel voor in ontwerpinterviews.

## Waarom het belangrijk is

```text
Estimating scale informs DESIGN decisions:
  → how many servers? how much storage? what database? do you need sharding/caching?
  → understanding the SCALE (small vs massive) shapes the whole design
→ rough numbers guide whether/how to scale (don't over- or under-engineer)
```

## Wat je moet schatten (back-of-the-envelope)

```text
✓ TRAFFIC → users, requests/sec (QPS); read vs write ratio (e.g. 100:1 reads:writes)
  → peak vs average (design for peak); daily active users → requests
✓ STORAGE → data size per item × volume × growth over time → total storage (and growth rate)
✓ BANDWIDTH → data transferred per second (request size × QPS)
✓ MEMORY → cache size needed (e.g. cache the hot 20% of data)
→ rough estimates (order of magnitude) → good enough to inform design
```

## Nuttige getallen en aanpak

```text
→ Know rough "latency numbers": memory ~ns, SSD ~µs, network/disk ~ms, cross-region ~100ms
→ Round numbers; use powers of 10; estimate, don't seek precision
→ Example: 1M daily users × 10 requests = 10M/day ≈ ~115 req/sec average (× peak factor)
→ derive resource needs from the estimates → justify the architecture
→ CAPACITY PLANNING → provision for expected load + growth + headroom; plan to scale
```

## Waarom het belangrijk is

Begrijpen hoe je schaal inschat en capaciteitsplanning uitvoert, is waardevol kennis op seniorniveau omdat **schattingen systeemontwerpen informeren** en een veelvoorkomend onderdeel zijn van ontwerpwerk en interviews, dus het is een nuttige, praktische vaardigheid.

Schaal inschatten — het berekenen van verwachte belasting, gegevensvolume en resourcebehoeften door middel van ruwe "back-of-the-envelope"-berekeningen — is belangrijk omdat **het begrijpen van de schaal het hele ontwerp bepaalt**: weten of een systeem duizenden of miljarden verzoeken afhandelt, bepaalt hoeveel je moet schalen, welke databases je gebruikt, en of sharding en caching nodig zijn, wat helpt zowel over-engineering (onnodige complexiteit voor kleine schaal) als onder-engineering (een ontwerp dat de werkelijke belasting niet aankan) te voorkomen.

Begrijpen **wat je moet schatten** — **verkeer** (gebruikers, verzoeken/seconde, lees-/schrijfverhoudingen, piek versus gemiddeld), **opslag** (gegevensgrootte en groei), **bandbreedte** en **geheugen-/cache**-behoeften — geeft het kader voor het dimensioneren van een systeem.

Begrijpen van de **aanpak** — kennis van ruwe latentiecijfers (geheugen versus SSD versus netwerk versus cross-region), het gebruik van ronde getallen en machten van 10, het schatten van orde van grootte in plaats van precisie, het afleiden van resourcebehoeften uit schattingen om de architectuur te rechtvaardigen, en **capaciteitsplanning** (resourcetoewijzing voor verwachte belasting plus groei en marge) — weerspiegelt de praktische vaardigheid om snel nuttige schattingen te maken.

Dit is een veelvoorkomende, verwachte vaardigheid in systeemontwerp-interviews (waarbij back-of-the-envelope-schattingen aantonen dat je kunt redeneren over schaal) en in werkelijke capaciteitsplanning.

Omdat schaal inschatten sleutelbeslissingen voor het ontwerp informeert (hoe je moet schalen, welke resources nodig zijn, het vermijden van over/onder-engineering) en een veelvoorkomend onderdeel van systeemontwerp-werk en interviews is, en omdat begrijpen wat je moet schatten en hoe je dat doet (back-of-the-envelope-berekeningen, latentiecijfers, capaciteitsplanning) een praktische vaardigheid is, is het begrijpen hoe je schaal inschat en capaciteitsplanning uitvoert, waardevol kennis op seniorniveau — een nuttige, verwachte vaardigheid voor systeemontwerp die architectuurbeslissingen informeert door ruwe kwantitatieve redenering, veelvoorkomend in zowel werkelijke capaciteitsplanning als ontwerpinterviews, en die de mogelijkheid weerspiegelt om ontwerpen te baseren op realistische schattingen van schaal en resourcebehoeften.