Jak odhadujete rozsah a jak provádíte plánování kapacity?

Question

Accepted Answer

**Odhadování a plánování kapacity** — výpočet očekávané zátěže, objemu dat a potřeb zdrojů — je důležitou součástí návrhu systému. Hrubé výpočty „na ubrousek" (back-of-the-envelope) ovlivňují návrhová rozhodnutí (jak moc škálovat, jaké zdroje jsou potřeba) a jsou běžné při návrhových pohovorech.

## Proč na odhadování záleží

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

## Co odhadovat (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
```

## Užitečná čísla a přístup

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

## Proč je to důležité

Porozumění tomu, jak odhadovat rozsah a jak plánovat kapacitu, je cenná znalost na seniorní úrovni, protože **odhad ovlivňuje rozhodnutí o návrhu systému** a je běžnou součástí návrhářské práce i pohovorů, takže jde o užitečnou a praktickou dovednost.

Odhadování rozsahu — výpočet očekávané zátěže, objemu dat a potřeb zdrojů pomocí hrubých výpočtů „na ubrousek" — je důležité, protože **pochopení rozsahu utváří celý návrh**: vědět, zda systém zvládá tisíce nebo miliardy požadavků, určuje, jak moc škálovat, jaké databáze použít a zda jsou potřeba sharding a cachování, což pomáhá vyhnout se jak přeinženýrování (zbytečná složitost pro malý rozsah), tak poddimenzování (návrh, který nezvládne skutečnou zátěž).

Pochopení toho, **co odhadovat** — **provoz** (uživatelé, požadavky/s, poměry čtení/zápisu, špička vs průměr), **úložiště** (velikost dat a růst), **propustnost** a potřeby **paměti/cache** — poskytuje rámec pro dimenzování systému.

Pochopení **přístupu** — znalost přibližných čísel latence (paměť vs SSD vs síť vs mezi regiony), používání zaokrouhlených čísel a mocnin 10, odhadování řádové velikosti místo hledání přesnosti, odvozování potřeb zdrojů z odhadů pro zdůvodnění architektury a **plánování kapacity** (zajištění zdrojů pro očekávanou zátěž plus růst a rezervu) — odráží praktickou dovednost rychle dělat užitečné odhady.

Jde o běžnou a očekávanou dovednost při pohovorech zaměřených na návrh systému (kde odhad „na ubrousek" ukazuje, že umíte uvažovat o rozsahu) i při reálném plánování kapacity.

Protože odhadování rozsahu ovlivňuje klíčová návrhová rozhodnutí (jak škálovat, jaké zdroje jsou potřeba, vyhnout se přeinženýrování/poddimenzování) a je běžnou součástí práce na návrhu systému i pohovorů, a protože pochopení toho, co a jak odhadovat (výpočty „na ubrousek", čísla latence, plánování kapacity), je praktickou dovedností, je porozumění tomu, jak odhadovat rozsah a plánovat kapacitu, cennou znalostí na seniorní úrovni — užitečnou a očekávanou dovedností pro návrh systému, která ovlivňuje architektonická rozhodnutí prostřednictvím hrubého kvantitativního uvažování, běžnou jak při reálném plánování kapacity, tak při návrhových pohovorech, a odrážející schopnost zakotvit návrhy v realistických odhadech rozsahu a potřeb zdrojů.