Při návrhu systému (System Design) brzy narazíš na otázku: stačí jeden server, nebo budu potřebovat cache, repliky a deset strojů? Odpověď ti dá odhad rozsahu — rychlý výpočet „na koleni", kolik requestů, dat a přenosu systém bude mít. Není to o přesných číslech, ale o řádu, který nasměruje rozhodnutí. A je to dovednost, na kterou se ptají skoro u každého system design pohovoru.
Pár pojmů na úvod
- QPS (queries per second) = kolik requestů systém zvládne/dostane za sekundu.
- Storage = kolik místa zaberou data.
- Bandwidth (přenosové pásmo) = kolik dat se přenese za sekundu.
- Peak (špička) = nárazové maximum, které bývá výrazně nad průměrem.
Čísla, která je dobré mít v hlavě
Aby odhad šel rychle z hlavy, pár zaokrouhlených konstant:
- Den má ~86 400 sekund ≈ 100 000 (10⁵). Šikovné: počet akcí za den vyděl 100 000 a máš zhruba QPS.
- Velikosti: tisíc ≈ 10³ (KB), milion ≈ 10⁶ (MB), miliarda ≈ 10⁹ (GB), bilion ≈ 10¹² (TB).
- Latence (z Performance): RAM nanosekundy, SSD ~100 µs, dotaz do DB ~ms, síť přes kontinent 100+ ms.
Zaokrouhluj zhurta. Cílem je řád („tisíce QPS", „stovky GB"), ne přesnost na desetinu.
Jak odhadovat — postup
- QPS: kolik akcí za den? Vyděl ~100 000 (sekund za den) → průměrné QPS. Pak vynásob špičkovým faktorem (provoz nebývá rovnoměrný; ve špičce klidně 2–10× průměr).
- Storage: kolik nových záznamů × jak velký jeden je × za jak dlouho (den, rok, 5 let).
- Bandwidth: QPS × velikost jedné odpovědi/requestu.
A hlavně urči poměr čtení ku zápisu — ten (jako v System Designu) určí celý tvar řešení (hodně čtení → cache + repliky; hodně zápisu → sharding + fronty).
Vzorový odhad — sdílení fotek
Řekněme appka s 2 miliony aktivních uživatelů denně, kteří dohromady nahrají 1 milion fotek za den (tj. zhruba každý druhý něco nahraje), a fotky se 100× víc prohlíží, než nahrávají.
- Zápisy (nahrání): 1 000 000 / den ÷ 100 000 = ~10 zápisů/s průměrně, ve špičce třeba ~30/s.
- Čtení (prohlížení): 100× víc = ~1 000 čtení/s průměrně. → Je to silně read-heavy → bude potřeba cache a CDN.
- Storage: 1 000 000 fotek/den × ~2 MB = ~2 TB/den, × 365 dní ≈ ~730 TB/rok syrových dat. ⚠️ Reálná faktura je 2–3× vyšší: object storage drží data replikovaně (typicky 3 kopie / erasure coding), a každou fotku navíc ukládáš v několika velikostech (náhledy/thumbnaily). Senior odhad s tímhle počítá. Tak jako tak: terabajty hned za první rok → object storage, ne disk serveru.
- Bandwidth (čtení): 1 000 čtení/s × 2 MB ≈ ~2 GB/s odchozího přenosu → rozhodně CDN, ať to neteče všechno z origin serveru.
Vidíš, jak pár hrubých čísel rovnou napoví architekturu: read-heavy → cache + CDN, velký objem dat → object storage, velký přenos → CDN. To je celý smysl odhadu.
Failure modes — kde se odhad pokazí
- Počítání jen průměru bez špičky → navrhneš na průměr a ve špičce to spadne.
- Zapomenutý růst v čase → storage „dnes stačí", ale za rok přeteče.
- Přehnaná přesnost → ztrácíš čas na desetinkách místo na řádu, který jediný rozhoduje.
- Ignorování read:write poměru → navrhneš špatný tvar systému (cache vs sharding).
🛠️ Cvičení
- QPS. Appka má 5 milionů akcí denně. Odhadni průměrné QPS a špičkové (faktor 5×).
- Storage za rok. Logovací služba zapíše 50 milionů řádků denně, jeden řádek ~1 KB. Kolik místa za rok?
- Bandwidth. API vrací odpovědi ~50 KB a má 2 000 QPS. Kolik je to odchozího přenosu za sekundu?
- Read:write. Pro feed (čtení 50× víc než zápis) a pro logovací službu (skoro jen zápis) urči poměr a co z toho plyne pro architekturu.
- Dotáhni odhad. Pro zkracovač URL odhadni QPS čtení i zápisu a řekni, proč z toho plyne potřeba cache.
Náčrt řešení — rozbal, až si cvičení zkusíš sám
- QPS — 5 milionů akcí ÷ 100 000 sekund ≈ ~50 QPS průměrně; × špičkový faktor 5 = ~250 QPS ve špičce. Pozor: navrhuj na špičkové číslo, ne na průměr — jinak ti to ve špičce spadne.
- Storage za rok — 50 milionů řádků/den × ~1 KB = ~50 GB/den; × 365 ≈ ~18 TB/rok syrových dat. Pozor: počítej s růstem a režií (indexy, replikace) — „dnes to stačí" za rok přeteče, terabajty logů patří do levného úložiště, ne na disk serveru.
- Bandwidth — 2 000 QPS × ~50 KB ≈ ~100 MB/s odchozího přenosu. Pozor: jde o řád (stovky Mbit/s až jednotky Gbit/s) — při takovém objemu zvaž CDN/cache, ať to neteče celé z origin serveru.
- Read:write — feed je read-heavy (50:1) → cache a read repliky; logovací služba je write-heavy (skoro jen zápis) → sharding a fronty, žádná cache. Pozor: samotný počet requestů ti tvar neřekne — rozhoduje až poměr čtení ku zápisu.
- Dotáhni odhad — u zkracovače URL je zápisů (vytvoření odkazu) málo, ale čtení (přesměrování) mnohonásobně víc → silně read-heavy. Proto cache: pár populárních odkazů obslouží drtivou většinu requestů z paměti místo dotazem do DB. Pozor: odhadni oba směry zvlášť, právě jejich poměr napoví cache.
🧠 Otázky & odpovědi
K čemu je odhad rozsahu (capacity estimation)?
Rychlý výpočet „na koleni", kolik requestů (QPS), dat a přenosu systém bude mít — abys ještě před návrhem věděl, jestli stačí jeden server, nebo potřebuješ cache, repliky a sharding. Nejde o přesná čísla, ale o řád, který nasměruje rozhodnutí. A je to dovednost, na kterou se ptají skoro u každého system design pohovoru.
Jak rychle odhadneš QPS z počtu akcí za den?
Využiješ, že den má ~100 000 sekund: počet akcí za den vyděl 100 000 a máš zhruba průměrné QPS. Pak ho vynásob špičkovým faktorem (2–10×), protože provoz nebývá rovnoměrný a navrhovat se musí na špičku, ne na průměr. Příklad: 1 milion akcí/den ÷ 100 000 = ~10 QPS průměrně.
Proč při odhadu nestačí počítat jen průměr?
Protože provoz není rovnoměrný — ve špičce (ráno, večer, po e-mailové kampani) bývá klidně několikrát vyšší než průměr. Když navrhneš kapacitu na průměr, ve špičce ti systém spadne. Vždy proto průměrné číslo vynásob špičkovým faktorem a navrhuj na špičku.
Proč je při odhadu klíčový poměr čtení ku zápisu?
Protože určuje celý tvar řešení. Hodně čtení (read-heavy) → potřebuješ cache a read repliky. Hodně zápisu (write-heavy) → potřebuješ rozdělit data (sharding) a fronty. Ze samotného počtu requestů to nepoznáš; teprve poměr čtení/zápis ti řekne, kam návrh směřovat — proto ho odhaduj zvlášť.
Proč u odhadu nehnat přesnost?
Protože rozhoduje řád, ne desetinky. Jestli vyjde „tisíce QPS" nebo „stovky GB", to ti řekne, co potřebuješ (cache, sharding, object storage) — a na tom se nic nezmění, ať je to 2 300 nebo 2 800 QPS. Honit přesná čísla je ztráta času; zaokrouhluj zhurta a soustřeď se na to, co z řádu plyne.