Škálovateľnosť webovej aplikácie: ako pripraviť systém na státisíce používateľov

01Stručná odpoveď: čo rozhoduje o tom, či aplikácia nápor vydrží

Škálovať sa dá dvoma smermi. Vertikálne znamená dať aplikácii silnejší server: viac procesorov a pamäte. Je to rýchle a jednoduché, má to však strop a jeden stroj zostáva jediným miestom, kde môže všetko zlyhať. Horizontálne znamená pridať ďalšie servery vedľa seba a rozdeliť medzi ne prácu. Strop je oveľa vyššie, aplikácia na to však musí byť pripravená.

Škálovateľnosť tiež nie je to isté čo rýchlosť. Aplikácia môže mať pre jedného používateľa odozvu 50 milisekúnd a pri tisícke súbežných používateľov sa zastaviť. Alebo naopak: je o niečo pomalšia, ale rovnako pomalá pri desiatich aj pri desiatich tisícoch ľudí. Tá druhá je škálovateľná, prvá nie.

02Státisíce používateľov neznamenajú státisíce požiadaviek za sekundu

Keď firma povie „potrebujeme aplikáciu pre 300 000 používateľov“, zvyčajne myslí registrované účty. Server však nezaujíma, koľko ľudí má účet. Zaujíma ho, koľko požiadaviek príde v najhoršej sekunde. Hrubý odhad sa dá vypočítať za päť minút:

Pre porovnanie: Stack Overflow v roku 2016 podľa svojho inžiniera Nicka Cravera obslúžil 209 miliónov HTTP požiadaviek za deň, v priemere vyše 2 400 za sekundu. Zvládlo to 11 webových serverov (z toho 2 na vývoj a meta) a 4 databázové servery SQL Server. Bežná firemná aplikácia so státisícmi účtov je teda záťaž, ktorú dobre postavený systém unesie na niekoľkých serveroch.

Háčik je v slove „špička“. Priemer nič nehovorí o chvíli, keď všetci prídu naraz: o 8:00 pri štarte registrácie, v nedeľu večer pred termínom alebo po odvysielaní reklamy. Práve vtedy padajú aj systémy, ktoré inak bežia bez problémov.

03Kde sa aplikácia láme: výpadky na Slovensku a v Česku

Verejne opísané výpadky štátnych systémov sú dobrá učebnica, lebo sa o nich písalo podrobne aj s technickými príčinami. Takmer vo všetkých sa ukázal rovnaký vzorec: príčinou nebol celý systém, ale jedno konkrétne miesto, s ktorým sa vopred nepočítalo.

• Objednávanie na očkovanie v Česku, 15. 1. 2021. Počas prvých dvoch minút prišlo 75 000 návštev. Systém sa zadrhával, hlavné úzke hrdlo však nebolo v samotnej aplikácii: PIN na prihlásenie chodil cez SMS a operátori ich rozosielali rýchlosťou 20 SMS za sekundu. Vo fronte ich čakalo vyše 40 000. Kapacitu brány sa podarilo zvýšiť na 200 SMS za sekundu až o pol hodiny neskôr.
• Objednávkový systém NCZI, 8. 3. 2021. Takmer hodinu výpadkov a spomalenia po zverejnení nových termínov. Podľa NCZI mala linka vládneho cloudu až 44 % stratených paketov a ďalším faktorom boli dobrovoľnícke portály, ktoré „nesystematicky volajú API rozhranie s voľnými termínmi“. Ján Suchal zo Slovensko.Digital upozornil, že zlý je už samotný princíp „kto prv príde, ten prv berie“. Ministerstvo zdravotníctva potom ohlásilo čakáreň.
• Sčítanie ľudu v Česku, 27. 3. 2021. Online formulár bol podľa českého portálu Lupa mimo prevádzky vyše desať hodín. Príčinou podľa dodávateľa bola chyba v module na vyplnenie adries s našepkávačom, ktorý preťažil databázové servery. Predseda Českého štatistického úradu uviedol, že chybu neodhalilo ani náročné testovanie vrátane nezávislej firmy.
• Aplikácia eDoklady pri českých voľbách, 3. 10. 2025. Vyše 1,5 milióna prihlásení za prvé štyri hodiny a preťažená časť na aktualizáciu dokladov. Česká Digitálna a informačná agentúra (DIA) priznala nesprávny odhad záťaže aj testovania a jej riaditeľ ponúkol rezignáciu.

Pri očkovaní, sčítaní ani v NCZI nešlo len o to, že by „bolo málo serverov“. Raz mala externá SMS brána svoj strop, inokedy jeden našepkávač vyťažil databázu a v prípade NCZI sa zlá sieťová linka stretla s návalom, ktorý vytvoril samotný spôsob uvoľňovania termínov. Pridať hardvér by tam pomohlo málo alebo vôbec nie. Pri eDokladoch v roku 2025 kapacita chýbala, no aj tam išlo o jednu konkrétnu časť aplikácie.

Nie každý výpadok súvisí so záťažou. Portál slovensko.sk v júli 2022 odstavilo prerušenie primárnej aj záložnej trasy medzi dátovými centrami, ktoré podľa NASES dodávateľ viedol súbežne. Aj to je lekcia: dve linky sú zálohou len vtedy, keď nevedú tou istou trasou.

04Čo ukázal verejný záťažový test eDokladov

Česká Digitálna a informačná agentúra 13. augusta 2026 skúsila niečo, čo český štát dovtedy neurobil: pozvala verejnosť, aby sa v rovnakej chvíli prihlásila do eDokladov. Zapojilo sa 30 tisíc používateľov a výsledky DIA zverejnila aj s číslami, ktoré si firmy zvyčajne nechávajú pre seba.

O 13:00 vzrástol počet súbežných spojení na vstupnej bráne za dve minúty takmer dvanásťnásobne. V najsilnejšej sekunde prišlo 1 712 požiadaviek. Aplikačné servery to zvládali: 95 % prihlásení vybavili do 20 milisekúnd a serverových chýb bolo len 0,06 %. Ľudia v mobilnej aplikácii napriek tomu čakali.

Medián odozvy vyskočil z 28 na 267 milisekúnd, 95 % požiadaviek skončilo do 22,2 sekundy a 99 % až do 33,5 sekundy. Podľa analýzy DIA nebol obmedzením výkon aplikačných serverov ani objem dát. Rozhodla rýchlosť, s akou vstupná brána Application Gateway dokázala pridávať kapacitu po skokovom náraste spojení.

Večerná vlna, ktorá prišla spontánne počas správ o 19:15, mala zhruba polovičný počet prihlásení (vyše 14 tisíc) a podobný objem dát, len rozložený do zhruba pol hodiny. Dopadla úplne inak: medián 29 milisekúnd, 99 % požiadaviek do 4,3 sekundy a 0,05 % chýb. DIA preto pred voľbami zvýši pripravenú kapacitu brány, aby pri náhlom náraste nemusela škálovať zo základnej úrovne.

Z testu plynú tri všeobecné poučenia. Automatické škálovanie nie je okamžité a na ohlásenú špičku je lepšie mať výkon pripravený vopred. Medián odozvy môže vyzerať v poriadku, zatiaľ čo každá dvadsiata požiadavka čaká vyše 20 sekúnd. A tvar nábehu rozhoduje rovnako ako počet ľudí: ten istý nápor za dve minúty je iný problém ako za pol hodiny.

05Koľko stojí výpadok a pomalá aplikácia

Cenu výpadku si musí každá firma vypočítať sama: stratené objednávky za hodinu, práca podpory, zľavy pre nahnevaných zákazníkov, zmluvné pokuty. Veľké prieskumy ukazujú skôr rád. Podľa Uptime Institute (správa Annual Outage Analysis 2026) 57 % prevádzkovateľov dátových centier uviedlo, že ich posledný veľký výpadok stál viac ako 100 000 USD, a každý piaty hlásil viac ako milión dolárov. Firma ITIC v prieskume z roku 2024 uvádza, že hodina výpadku stojí vyše 90 % stredných a veľkých podnikov viac ako 300 000 USD.

Pre menšiu firmu sú tie čísla privysoké. ITIC uvádza aj príklad z jej sveta: aj firma, ktorá hodinu výpadku odhadne na 10 000 USD, prichádza o 167 USD za každú minútu. Často citované číslo „5 600 dolárov za minútu“ od Gartnera pochádza z blogu analytika Andrewa Lernera z roku 2014, týka sa výpadkov siete a podľa jeho vlastných slov ide o priemer s veľkým rozptylom.

Pomalosť stojí peniaze aj bez výpadku

Štúdia Deloitte Milliseconds Make Millions z roku 2020, ktorú zadal Google, sledovala 37 značiek a 30 miliónov návštev. Pri zrýchlení mobilného webu o desatinu sekundy vzrástli konverzie v maloobchode o 8,4 % a v cestovnom ruchu o 10,1 %. Ide o súvislosť, nie o kontrolovaný pokus. Čistý experiment opísal Ronny Kohavi z Microsoftu: keď vyhľadávač Live Search spomalil výsledky o sekundu, používatelia zadali o 1 % menej dopytov a na reklamy klikli o 1,5 % menej.

Slávne „Amazon stráca 1 % tržieb za každých 100 ms“ má jediný primárny zdroj: riadok na snímke bývalého inžiniera Amazonu Grega Lindena z prednášky v roku 2006, bez opisu metodiky. Smer platí, presné číslo pre dnešný web nie.

Slovenskí nakupujúci podľa Eurostatu na tento problém narážajú zriedkavo. Že bol web príliš zložitý alebo fungoval neuspokojivo, uviedlo v roku 2025 len 5,3 % Slovákov, ktorí v posledných troch mesiacoch nakupovali na internete, kým priemer EÚ bol 11,5 %. Pozor však na porovnávanie krajín: časť rozdielu môže spôsobiť aj preklad otázky v dotazníku. Ako rýchlosť a zrozumiteľnosť ovplyvňujú, či sa ľudia do aplikácie vracajú, rozoberáme v článku UX dizajn webovej aplikácie.

06Databáza: zvyčajne prvé úzke hrdlo

Aplikačný server sa dá skopírovať a spustiť desaťkrát. Databáza s dátami, ktoré musia byť všade rovnaké, nie. Preto sa mnoho aplikácií pod záťažou zadrhne práve tu. Ukázal to aj výpadok českého sčítania: jeden našepkávač adries posielal do databázy viac práce, ako zvládla.

1. Indexy a pomalé dopyty

Dopyt, ktorý na testovacej databáze s tisíckou riadkov trvá milisekundu, môže na milióne riadkov trvať stovky milisekúnd aj viac, lebo databáza prechádza celú tabuľku. Skôr ako začnete kupovať výkonnejší server, pozrite sa, ako databáza dopyt vykonáva, a pridajte index na stĺpce, podľa ktorých sa vyhľadáva a triedi. V PostgreSQL to vyzerá napríklad takto:

EXPLAIN ANALYZE
SELECT id, total FROM orders
WHERE customer_id = 4821
ORDER BY created_at DESC
LIMIT 20;

CREATE INDEX CONCURRENTLY idx_orders_customer_created
  ON orders (customer_id, created_at DESC);

Častou chybou je aj takzvaný problém N+1: aplikácia načíta zoznam 50 objednávok a potom ku každej zvlášť dopytom dohľadá zákazníka. Namiesto jedného dopytu ich pošle 51. Pri desiatich používateľoch to nikto nespozná, pri desiatich tisícoch to databázu zloží.

2. Pool spojení

Každé spojenie do databázy stojí pamäť. PostgreSQL má v predvolenom nastavení limit zvyčajne 100 súbežných spojení a jeho zvýšenie znamená viac zdieľanej pamäte. Keď aplikácia beží na desiatich serveroch a každý si otvorí 20 spojení, limit je preč. Riešením je pool spojení, napríklad PgBouncer, ktorý v režime transakcií prideľuje spojenie len na čas jednej transakcie. Wiki PostgreSQL k tomu výslovne píše, že menej spojení s frontom často obslúži viac súbežných používateľov ako veľa spojení naraz.

3. Repliky na čítanie a rozdelenie databázy

Väčšina aplikácií dáta viac číta, ako zapisuje. Kópie databázy určené len na čítanie (repliky) prevezmú prehľady, vyhľadávanie a reporty, hlavná databáza potom rieši zápisy. Repliky mierne zaostávajú, preto čítanie hneď po zápise (napríklad potvrdenie objednávky) smerujte na hlavnú databázu. Ďalší krok je rozdeliť dáta podľa modulov do samostatných databáz, napríklad fakturáciu zvlášť a zvlášť analytiku.

Až úplne nakoniec prichádza sharding, teda rozdelenie jednej veľkej tabuľky medzi viac databázových serverov. Dá sa to zvládnuť, ale je to drahé. Notion podľa svojho blogu vydržal na jednej databáze PostgreSQL päť rokov a štyri rády rastu, v roku 2021 prešiel na 480 logických shardov na 32 databázach a v roku 2023 počet strojov strojnásobil na 96. Figma v roku 2020 bežala na jedinej databáze PostgreSQL na najväčšej inštancii, akú AWS ponúkal. Skôr ako rozdelila prvú tabuľku, siahla po replikách, vyrovnávacej pamäti a vertikálnom delení a samotné rozdelenie prvej tabuľky jej trvalo zhruba deväť mesiacov.

Pre firmu, ktorá čaká státisíce používateľov, z toho plynie jednoduchá rada: vyberte spoľahlivú relačnú databázu, navrhnite dobre tabuľky a indexy a sharding neplánujte vopred. Ak sa k nemu raz dostanete, bude to znamenať, že sa produktu darí.

07Vyrovnávacia pamäť a CDN: najlacnejší výkon, aký môžete mať

Najrýchlejšia požiadavka je tá, ktorá k vašej aplikácii vôbec nepríde. Obrázky, skripty, štýly a verejné stránky môže doručovať CDN, teda sieť serverov blízko používateľov. Výsledky častých dopytov môže aplikácia držať vo vyrovnávacej pamäti (cache), zvyčajne v Redise, a do databázy siahať, len keď údaj vo vyrovnávacej pamäti chýba alebo vypršal.

Koľko práce vie okrajová vrstva prevziať, naznačujú čísla Shopify z Black Friday a Cyber Monday 2025. V špičke prišlo 489 miliónov požiadaviek za minútu na okrajovú vrstvu (edge), kým aplikačné servery vrcholili na niečo vyše 117 miliónoch, teda zhruba na štvrtine. Stack Overflow v roku 2016 vykonal v Redise zhruba 160 miliárd operácií mesačne a žiadna inštancia pritom neprekročila 2 % vyťaženia procesora.

Vyrovnávacia pamäť má dve pasce. Prvou sú zastarané dáta: pri cene, skladovej zásobe alebo stave objednávky musíte presne vedieť, kedy sa cache maže. Druhou je chvíľa, keď cache vyprší a tisíc požiadaviek naraz zamieri do databázy po ten istý údaj. Discord to rieši zlučovaním: keď viac používateľov chce v tej istej chvíli rovnaký riadok, databáza dostane len jeden dopyt.

08Bezstavová aplikácia: podmienka na pridávanie serverov

Horizontálne škálovanie funguje, len keď je jedno, na ktorý server požiadavka dorazí. Aplikačný server si preto nesmie nič pamätať len u seba:

• Prihlásenie patrí do podpísaného tokenu alebo do zdieľaného úložiska relácií.
• Nahraté súbory patria do objektového úložiska (S3 a podobné služby), disk servera je len dočasný.
• Plánované úlohy musia bežať raz, nie na každom serveri zvlášť, inak zákazník dostane ten istý e-mail desaťkrát.
• Konfigurácia sa načítava z premenných prostredia, aby nový server nabehol bez ručného nastavovania.

Keď toto platí, stačí pred aplikáciu postaviť load balancer a servery pridávať podľa záťaže. AWS to vo svojich odporúčaniach pre spoľahlivosť zhŕňa dvoma princípmi: nahradiť jeden veľký zdroj niekoľkými menšími, aby výpadok jedného neohrozil celok, a prestať hádať kapacitu, teda pridávať a uberať výkon automaticky podľa skutočného dopytu.

Test eDokladov však ukázal, že automatické škálovanie potrebuje čas. Na známe špičky (štart predaja, kampaň, uzávierka) preto nastavte vyššie minimum vopred a automatike nechajte len to, čo nečakáte.

09Fronty a čakárne: čo nemusí prebehnúť hneď

Používateľ po kliknutí na „Odoslať objednávku“ potrebuje vedieť, že objednávka prešla. Nepotrebuje čakať, kým sa vygeneruje PDF faktúra, odošle e-mail a zapíše sa záznam do účtovného systému. To všetko môže prevziať front úloh a spracovať to o pár sekúnd neskôr na pozadí.

Front zároveň chráni pred limitmi cudzích služieb. České objednávanie na očkovanie v januári 2021 narazilo presne na toto: za prvú hodinu prišlo 44 tisíc registrácií, ale SMS s PIN kódom odchádzali rýchlosťou 20 za sekundu a vo fronte ich čakalo vyše 40 000. Front tam bol, chýbala však vopred dohodnutá kapacita u operátorov a jasná správa používateľom. S ňou je čakanie nepríjemnosť. Bez nej ľudia klikajú znova a znova a záťaž násobia.

Pri akciách, kde sa čaká nápor v jednej chvíli (vstupenky, registrácie, obmedzené termíny), pomáha virtuálna čakáreň. Aplikácia pustí dnu toľko ľudí, koľko zvládne, a ostatným ukáže poradie. Presne takú čakáreň ohlásilo ministerstvo zdravotníctva po výpadku NCZI. Ešte lepšie je nápor vôbec nevytvoriť: termíny uvoľňovať postupne alebo po skupinách, nie všetky naraz o jednej hodine.

Ak aplikácia komunikuje s ďalšími systémami, prečítajte si aj článok Prepojenie systémov cez API. Limity počtu dopytov, opakovanie a chyby na strane partnera tam rozoberáme podrobne.

10Monolit, alebo mikroslužby?

Mikroslužby rozdelia aplikáciu na desiatky samostatných častí, ktoré sa nasadzujú a škálujú zvlášť. Veľkým firmám so stovkami vývojárov to dáva zmysel. Malému tímu to často prinesie najmä viac práce s prevádzkou.

Segment v roku 2018 opísal, ako zlúčil vyše 140 služieb na doručovanie dát späť do jednej. Predtým traja inžinieri na plný úväzok trávili väčšinu času len tým, aby systém vôbec bežal. Tím Amazon Prime Video v roku 2023 prestaval jednu monitorovaciu službu z rozdrobenej serverless architektúry na jeden celok a znížil náklady na infraštruktúru o viac ako 90 %. Oboje sa týkalo jednej časti firmy, nie celého produktu, ale ukazuje to, že rozdelenie na viac služieb samo osebe výkon nepridá.

Instagram v roku 2016 písal o najväčšom nasadení frameworku Django na svete a o viac ako 500 miliónoch používateľov. Stack Overflow v tom istom roku uvádzal, že celú jeho sieť otázok a odpovedí by v núdzi obslúžil jediný webový server. Ani jeden z nich nepotreboval na taký rast rozbiť aplikáciu na desiatky služieb.

Pre väčšinu firemných aplikácií a SaaS produktov preto odporúčame modulárny monolit: jedna aplikácia s jasne oddelenými modulmi (používatelia, objednávky, fakturácia), ktoré spolu komunikujú cez definované rozhrania. Keď raz jeden modul začne potrebovať vlastné škálovanie alebo vlastný tím, dá sa vyčleniť. Opačne to ide oveľa ťažšie.

Podobné je to s Kubernetes. Podľa prieskumu CNCF ho v produkcii prevádzkuje 82 % tých, ktorí používajú kontajnery, lenže odpovedajú najmä ľudia z komunity okolo cloud native technológií. Medzi všetkými vývojármi v prieskume Stack Overflow 2025 s ním intenzívne pracovalo 28,5 %. Pre aplikáciu so státisícmi používateľov často stačí spravovaná platforma, na ktorej sa o servery starať nemusíte.

11Meranie: bez neho škálujete naslepo

Skôr ako čokoľvek optimalizujete, potrebujete vidieť, čo sa v aplikácii deje. Minimum pre produkčnú aplikáciu:

• Odozva v percentiloch. Priemer aj medián skryjú problém. Sledujte medián, 95. a 99. percentil, teda za aký čas dostane odpoveď 95 a 99 požiadaviek zo sto. Pri eDokladoch bol medián pri prudkom nábehu 267 milisekúnd, ale 99. percentil 33,5 sekundy.
• Podiel chýb. Koľko požiadaviek skončí chybou servera, rozdelené podľa častí aplikácie.
• Vyťaženie zdrojov. Procesor, pamäť, počet spojení do databázy, dĺžka frontu úloh.
• Najpomalšie dopyty do databázy. PostgreSQL ich vie zapisovať do logu sám.
• Upozornenia. Keď niečo prekročí limit, musí sa to niekto z tímu dozvedieť skôr, ako zavolá zákazník.

Druhá vec je dohodnúť sa, aká spoľahlivá má aplikácia byť. Google vo svojej knihe o prevádzke (Site Reliability Engineering) odporúča stanoviť cieľ dostupnosti a z neho odvodiť rozpočet chýb: koľko výpadkov si môžete dovoliť, kým zastavíte nové funkcie a začnete opravovať. Služba, ktorá za deň obslúži 2,5 milióna požiadaviek s cieľom 99,99 %, môže vrátiť najviac 250 chýb.

Každá deviatka navyše stojí peniaze: záložné servery, druhé dátové centrum, ľudia v pohotovosti. Google sám upozorňuje, že používateľ na telefóne s 99 % spoľahlivosťou rozdiel medzi 99,99 % a 99,999 % nespozná. Pre firemnú aplikáciu je 99,9 % rozumný štart, pre platby a zdravotníctvo viac.

12Záťažové testy: ako ich urobiť, aby mali zmysel

Záťažový test webovej aplikácie simuluje návštevníkov a meria, kedy sa systém začne spomaľovať a kedy padá. Nástroj k6 od Grafany rozlišuje šesť typov testov: dymový (smoke) overí, že test vôbec funguje, test priemernej záťaže bežnú prevádzku, stresový test záťaž nad priemerom, dlhodobý (soak) správanie po hodinách, test špičky (spike) náhly nápor a test bodu zlomu hľadá, kde je strop.

Takto vyzerá jednoduchý test špičky: dve minúty pozvoľný nábeh na 50 používateľov, potom počas 30 sekúnd 2 000 virtuálnych používateľov a päť minút plnej záťaže. Test neprejde, ak zlyhá 1 % požiadaviek alebo viac, ak je 95. percentil odozvy dlhší ako 800 milisekúnd alebo 99. percentil dlhší ako 2 sekundy.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },
    { duration: '30s', target: 2000 },
    { duration: '5m', target: 2000 },
    { duration: '1m', target: 0 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<800', 'p(99)<2000'],
  },
};

export default function () {
  http.get('https://test.vasa-aplikacia.sk/api/terminy');
  sleep(1);
}

Aby test niečo odhalil, musí sa čo najviac podobať na realitu:

1. Testujte celú cestu používateľa, nie jednu stránku. České sčítanie padlo na našepkávači adries, teda na časti, ktorú jednoduchý test prihlásenia nezachytí.
2. Použite dáta v produkčnej veľkosti. Dopyt nad prázdnou databázou je vždy rýchly.
3. Skúšajte aj prudký nábeh, nielen pomalé pridávanie používateľov. Test eDokladov ukázal, že podobný objem prevádzky rozložený do pol hodiny je úplne iná situácia.
4. Zahrňte externé služby alebo ich vernú náhradu a zistite si ich limity. Platobná brána, SMS a registre majú svoj strop.
5. Test zopakujte po každej väčšej zmene a pred každou ohlásenou akciou. Shopify pred Black Friday 2025 urobil od apríla do októbra päť veľkých testov a vo štvrtom dosiahol 146 miliónov požiadaviek za minútu.

Nikdy netestujte produkciu bez dohody s poskytovateľom hostingu. Záťažový test zo stoviek strojov vyzerá ako útok a môže skončiť zablokovaním.

13Cloud, alebo vlastný server: koľko stojí výkon

Platený cloud používalo podľa Eurostatu v roku 2025 len 36,4 % slovenských firiem s desiatimi a viac zamestnancami, výrazne menej ako priemer EÚ (52,7 %) aj Česko (54,9 %). Väčšinou ide navyše o e-mail a kancelárske programy. Za výpočtový výkon pre vlastné aplikácie platilo 9,8 % firiem.

Samotný server je prekvapivo lacná položka. Porovnanie strojov s 2 procesorovými jadrami a 8 GB pamäte ukazuje, že aj v cloude AWS stojí jeden taký server v prepočte do 80 € mesačne:

Skutočné náklady tvorí spravovaná databáza, prenosy dát, zálohy, monitoring a najmä čas ľudí, ktorí sa o prevádzku starajú. Podľa správy Flexera 2026 firmy odhadujú, že 29 % výdavkov na cloud minú zbytočne. Opačným príkladom je 37signals (Basecamp, HEY), ktorá presunula aplikácie z cloudu na vlastné servery a ročný účet za cloud znížila z 3,2 milióna na 1,3 milióna dolárov (za nový hardvér jednorazovo zaplatila zhruba 700 000 dolárov). Jej spoluzakladateľ David Heinemeier Hansson však sám píše, že cloud dáva zmysel na začiatku a pri veľkých výkyvoch záťaže.

Praktické pravidlo: kým produkt hľadá zákazníkov, plaťte za spravované služby a šetrite čas vývojárov. Keď máte stabilnú a predvídateľnú prevádzku a účet za cloud sa stane významnou položkou, vypočítajte si prechod na prenajaté alebo vlastné servery. O plánovaní rozpočtu a nákladov na prevádzku píšeme v článku Ako naplánovať vývoj SaaS aplikácie.

14Plán podľa fáz: čo riešiť pri 1 000, 10 000 a 100 000 používateľoch

Ide o naše odporúčanie z praxe. Hranice sú orientačné a počítajú aktívnych používateľov za deň, nie registrované účty. Rezervačná aplikácia s rannou špičkou sa môže dostať do vyššej fázy skôr ako interný systém s rovnomernou prevádzkou.

1. Do 1 000 aktívnych používateľov denne. Jedna aplikácia, spravovaná databáza s automatickými zálohami, CDN na statické súbory, sledovanie chýb a základné meranie odozvy. Hlavne si nezatvárať cestu: žiadne súbory a relácie na disku servera.
2. Do 10 000. Prejsť najpomalšie dopyty a doplniť indexy, zapnúť pool spojení, pridať cache na najčastejšie dáta a front na e-maily, exporty a PDF. Prvý záťažový test s realistickými dátami.
3. Do 100 000. Viac inštancií aplikácie za load balancerom, automatické škálovanie s rozumným minimom, repliky databázy na čítanie, ciele dostupnosti a rozpočet chýb. Záťažový test pred každou väčšou akciou vrátane prudkého nábehu.
4. Státisíce a viac. Rozdelenie databázy podľa modulov, čakáreň pre nárazové akcie, oddelenie kritických častí (prihlásenie, platby) od zvyšku, nacvičená obnova po výpadku. Sharding alebo samostatné služby len tam, kde to meranie naozaj ukáže.

Najdrahšie je preskočiť fázy oboma smermi: postaviť pre prvú stovku zákazníkov zložitý systém z mikroslužieb, alebo naopak ignorovať prvé tri body a riešiť ich až uprostred kampane.

15Ako zistiť, či je vaša aplikácia pripravená

Skôr ako minete peniaze na silnejšie servery, prejdite si osem otázok. Každé „neviem“ je úloha pre vývojárov:

Pri nových projektoch je najlacnejšie myslieť na tieto body od začiatku. Návrh architektúry, záťažové testy a monitoring sú pri webových aplikáciách, ktoré staviame, súčasťou vývoja a neplatíte za ne navyše. Ako projekt prebieha, nájdete na stránke Ako to prebieha, orientačné ceny v cenníku.

Škálovanie sa týka aj bezpečnosti: s počtom používateľov rastie aj to, čo je v databáze v stávke. Na čo myslieť, opisuje článok Bezpečnosť dát v systéme na mieru.

16Najčastejšie chyby pri škálovaní

• Kupovať výkonnejší server skôr, ako viete, čo je pomalé. Pomôže na týždeň, potom sa problém vráti väčší.
• Testovať len prihlásenie a úvodnú stránku. Aplikácie padajú na konkrétnych funkciách: našepkávač, export, vyhľadávanie.
• Testovať nad prázdnou databázou. Výsledok bude skvelý a nanič.
• Spoliehať sa na automatické škálovanie pri ohlásenej špičke. Výkon potrebuje minúty na nábeh, ľudia vydržia čakať len pár sekúnd.
• Ignorovať limity cudzích služieb. SMS brána, platby alebo registre zastavia aj aplikáciu, ktorá by inak vydržala.
• Sledovať len priemernú odozvu alebo medián. Medián vyzerá dobre, aj keď každá dvadsiata požiadavka čaká desiatky sekúnd.
• Začať s mikroslužbami kvôli budúcemu rastu. Malý tím potom strávi viac času prevádzkou ako produktom.
• Pustiť všetkých ľudí v jednej chvíli. Termíny, zľavy a registrácie sa dajú často rozložiť a problém tým zmizne.

17Časté otázky

18Zdroje

• Startitup Fontech: Štátna IT katastrofa pri prihlasovaní na očkovanie (9. 3. 2021)
• MojAndroid.sk: NCZI a údajný DDoS útok (2021)
• MojAndroid.sk: Výpadok slovensko.sk (2022)
• DIA: Analýza verejného testu eDokladov (18. 8. 2026, po česky)
• DIA: eDoklady pri voľbách, skúsenosti a poučenie (7. 10. 2025, po česky)
• Lupa.cz: Sčítanie ľudu 2021, online formulár nedostupný (po česky)
• Lupa.cz: Rezervačný systém na očkovanie, 75 tisíc ľudí v prvých minútach (po česky)
• Eurostat: Problémy pri nákupe cez web alebo aplikáciu (isoc_ec_iprb21)
• Eurostat: Cloud computing services by size class of enterprise (isoc_cicce_use)
• Uptime Institute: Annual Outage Analysis 2026
• ITIC: 2024 Hourly Cost of Downtime a časť 2
• Deloitte a Google: Milliseconds Make Millions (PDF, 2020)
• Kohavi a kol.: Controlled experiments on the web (PDF, 2009)
• Nick Craver: Stack Overflow, The Architecture, 2016 Edition
• Notion: Herding elephants, sharding Postgres at Notion a The Great Re-shard
• Figma: How Figma’s databases team lived to tell the scale
• Discord: How Discord stores trillions of messages
• Shopify: výsledky Black Friday Cyber Monday 2025 a príprava na BFCM 2025
• Segment: Goodbye Microservices (2018)
• Amazon Prime Video: zníženie nákladov o 90 % (archív, 2023)
• PostgreSQL: Connections and Authentication a PgBouncer: Features
• AWS Well-Architected: Reliability pillar, design principles
• Google SRE: Availability table a Embracing risk
• Grafana k6: Load test types
• Flexera: State of the Cloud 2026 a CNCF Annual Cloud Native Survey 2025
• 37signals: Our cloud exit savings will now top ten million over five years
• Hetzner: úprava cien 2026, VEDOS VPS ON, AWS EC2 On-Demand
• ECB: referenčné výmenné kurzy