Keď štátne e-služby padnú: Architektonické princípy pre spoľahlivé verejné systémy

Výpadok elektronického katastra nehnuteľností (ESKN) v januári 2026 opäť pripomenul dlhodobý problém slovenskej verejnej správy. Kritické e-služby sú krehké. Realitné kancelárie, notári a advokáti nemohli pracovať. Občania si nevedeli preveriť vlastníctvo nehnuteľností. Úrad geodézie komunikoval zdržanlivo a neurčito. Kto bol prekvapený, nech zdvihne ruku. Nikto? Presne tak.

Nie je to prvý ani posledný takýto výpadok. Je to však príležitosť pozrieť sa na to, čo by sa malo robiť inak.

Prečo štátne systémy padajú

Väčšina kritických štátnych systémov na Slovensku vznikla v ére, keď sa o cloude, kontajnerizácii alebo mikroslužbách len snívalo. Vidno to na ich stavbe. Sú monolitické, takže zlyhanie jedinej časti položí celok. Bežia na jednom serveri alebo v jednom dátovom centre, takže pri jeho výpadku niet kam prepnúť.

K tomu sa pridáva vek. Časť systémov stojí na technológiách, ktoré už nikto nepodporuje, takže na známu zraniteľnosť nepríde záplata. A keď systému rozumie iba pôvodný dodávateľ, štát nemá s kým súťažiť o modernizáciu.

Architektonické princípy pre spoľahlivé e-služby

Design for Failure

Každý komponent raz zlyhá a systém s tým musí rátať. Circuit breaker odreže zaseknutú závislosť, aby jedna pomalá služba nestiahla so sebou zvyšok. Graceful degradation nechá použiteľné aspoň to, čo funguje, namiesto bielej obrazovky. A automatický failover prehodí prevádzku na záložnú inštanciu, kým všetci spia.

Observability od prvého dňa

Nemôžete opraviť to, čo nevidíte. Moderný systém potrebuje štyri veci naraz:

• všetky logy na jednom mieste a prehľadávateľné
• metriky v reálnom čase, teda CPU, pamäť, response time a error rate
• distribuované trasovanie, aby sa dala požiadavka sledovať naprieč komponentmi
• alerting, ktorý sa ozve skôr, ako problém nahlási prvý používateľ

Bez nich je ladenie výpadku hádanie.

Škálovateľnosť a redundancia

Kritická služba musí bežať minimálne v dvoch nezávislých prostrediach. Prakticky to znamená nasadenie do viacerých zón alebo regiónov, load balancing medzi inštanciami a databázovú replikáciu, ktorá pri výpadku prepne na repliku sama.

Automatizovaný deployment a rollback

Manuálne nasadzovanie je recept na katastrofu. CI/CD pipeline s automatickými testami zachytí chybu skôr, ako sa dostane k občanom. Blue-green a canary stratégie púšťajú novú verziu najprv na malú časť prevádzky. A keď sa aj tak niečo pokazí, návrat na predošlú verziu má trvať minúty, nie hodiny.

Transparentná komunikácia počas výpadku

Výpadok ESKN ukázal, že komunikácia je rovnako dôležitá ako technická odolnosť. Status page v reálnom čase povie ľuďom, na čom sú. Príspevok na Facebooku o tri hodiny neskôr to nedokáže. SLA s definovanými časmi odozvy dáva tomu sľubu váhu. Po incidente má prísť report s príčinou a s tým, čo sa zmení.

Záťažové testy pritom nepatria len pred spustenie. Prevádzka sa v čase mení, takže testovať treba aj počas nej.

Čo sa môžeme naučiť zo súkromného sektora

Banky, e-shopy a SaaS firmy riešia rovnaké výzvy a väčšina ich už vyriešila. Rozdiel je v motivácii. Súkromný sektor platí za každú minútu výpadku priamo, verejná správa túto spätnú väzbu nemá.

Riešenie nie je v tom, že štát začne nakupovať drahšie technológie. Je v tom, že začne uplatňovať overené inžinierske princípy.

Failover pritom nie je dôkazom odolnosti len preto, že je nakreslený v architektúre. Treba ho pravidelne skúšať riadeným prepnutím, merať čas obnovy a overiť, či záložná cesta zvládne reálnu prevádzku.

Keď budujeme systém, myslíme aj na to, čo sa stane, keď niečo zlyhá. Niečo vždy zlyhá. Otázka je len kedy.

Výpadky štátnych e-služieb nie sú nevyhnutnosť. Sú dôsledkom architektonických rozhodnutí alebo ich absencie. Princípy, ktoré fungujú v súkromnom sektore, fungujú aj vo verejnom. Stačí ich začať uplatňovať.

Ak budujete systém, ktorý musí byť spoľahlivý, porozprávajme sa o tom, ako to dosiahnuť.