Hogyan becsüli meg a skálázást és végez kapacitástervezést?

Question

Accepted Answer

**Becslés és kapacitástervezés** — a várható terhelés, adatmennyiség és erőforrásigény kiszámítása — a rendszertervezés fontos része. A durva "papíron végzett" számítások (back-of-the-envelope) informálják a tervezési döntéseket (mennyire kell skálázni, milyen erőforrások szükségesek) és a tervezési interjúkban gyakoriak.

## Miért fontos a becslés

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

## Mit kell becsülni (papíron végzett számítások)

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

## Hasznos számok és megközelítés

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

## Miért számít

A skálázás becslésének és kapacitástervezésének módja értékes senior szintű ismeret, mert **a becslések informálják a rendszertervezési döntéseket** és a tervezési munka és interjúk gyakori része, így hasznos, gyakorlati készség.

A skálázás becslése — a várható terhelés, adatmennyiség és erőforrásigény durva „papíron végzett