Hvordan estimerer du skala og gjør kapasitetsplanlegging?

Question

Accepted Answer

**Estimering og kapasitetsplanlegging** — beregning av forventet belastning, datamengde og ressursbehov — er en viktig del av systemdesign. Grove "back-of-the-envelope"-beregninger informerer designbeslutninger (hvor mye skal skaleres, hvilke ressurser trengs) og er vanlige i designintervjuer.

## Hvorfor estimering er viktig

```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)
```

## Hva du skal estimere (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
```

## Nyttige tall og fremgangsmåte

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

## Hvorfor det er viktig

Å forstå hvordan man estimerer skala og gjør kapasitetsplanlegging er verdifull kunnskap på seniornivå fordi **estimering informerer systemdesignbeslutninger** og er en vanlig del av designarbeid og intervjuer, så det er en nyttig, praktisk ferdighet.

Å estimere skala — beregne forventet belastning, datamengde og ressursbehov gjennom grove "back-of-the-envelope"-beregninger — er viktig fordi **å forstå skalaen former hele designet**: å vite om et system håndterer tusenvis eller milliarder av forespørsler bestemmer hvor mye det skal skaleres, hvilke databaser som skal brukes, og om fragmentering og caching er nødvendig, og hjelper til å unngå både over-engineering (unødvendig kompleksitet for liten skala) og under-engineering (et design som ikke kan håndtere den virkelige belastningen).

Å forstå **hva som skal estimeres** — **trafikk** (brukere, forespørsler/sek, lese/skrive-forhold, toppbelastning vs gjennomsnitt), **lagring** (datastørrelse og vekst), **båndbredde** og **minne/cache**-behov — gir rammeverket for å dimensjonere et system.

Å forstå **fremgangsmåten** — å kjenne grove latenstall (minne vs SSD vs nettverk vs tvers over regioner), å bruke runde tall og tierpotenser, å estimere størrelsesorden heller enn å søke presisjon, å utlede ressursbehov fra estimater for å rettferdiggjøre arkitekturen, og **kapasitetsplanlegging** (tilveiing for forventet belastning pluss vekst og sikkerhetsmarg) — gjenspeiler den praktiske ferdigheten å lage nyttige estimater raskt.

Dette er en vanlig, forventet ferdighet i systemdesignintervjuer (hvor back-of-the-envelope-estimering viser at du kan resonnere om skala) og i virkelig kapasitetsplanlegging.

Ettersom estimering av skala informerer viktige designbeslutninger (hvordan skal skaleres, hvilke ressurser trengs, unngå over/under-engineering) og er en vanlig del av systemdesignarbeid og intervjuer, og siden å forstå hva som skal estimeres og hvordan (back-of-the-envelope-beregninger, latenstall, kapasitetsplanlegging) er en praktisk ferdighet, er å forstå hvordan man estimerer skala og gjør kapasitetsplanlegging verdifull kunnskap på seniornivå — en nyttig, forventet ferdighet for systemdesign som informerer arkitektoniske beslutninger gjennom grov kvantitativ resonnering, vanlig både i virkelig kapasitetsplanlegging og designintervjuer, og gjenspeiler evnen til å grunnfeste design i realistiske estimater av skala og ressursbehov.