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 – krehkosť kritických e-služieb. Realitné kancelárie, notári a advokáti nemohli pracovať. Občania nemohli 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. Ale je to 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 cloud, kontajnerizácii alebo mikro-službách len snívalo. Typické problémy zahŕňajú:

• Monolitická architektúra, jeden komponent zlyhá a spadne celý systém
• Žiadna redundancia, systém beží na jednom serveri alebo v jednom dátovom centre
• Zastaralé technológie – Systémy postavené na technológiách, pre ktoré už neexistuje podpora
• Vendor lock-in – Závislosť na jednom dodávateľovi, ktorý nemá motiváciu modernizovať

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

1. Design for Failure

Každý komponent systému môže zlyhať – a systém s tým musí počítať. To znamená:

• Circuit breakers medzi komponentmi
• Graceful degradation namiesto úplného výpadku
• Automatické failover na záložné inštancie

2. Observability od prvého dňa

Nemôžete opraviť to, čo nevidíte. Moderné systémy potrebujú:

• Centralizovaný logging – Všetky logy na jednom mieste, prehľadávateľné
• Metriky v reálnom čase – CPU, pamäť, response time, error rate
• Distribuované trasovanie – Schopnosť sledovať požiadavku naprieč komponentmi
• Alerting – Automatické upozornenia skôr, ako si problém všimnú používatelia

3. Škálovateľnosť a redundancia

Kritické služby musia bežať minimálne v dvoch nezávislých prostrediach:

• Multi-zone alebo multi-region deployment
• Load balancing medzi inštanciami
• Databázová replikácia s automatickým failover

4. Automatizovaný deployment a rollback

Manuálne nasadzovanie je recept na katastrofu:

• CI/CD pipeline s automatickými testami
• Blue-green alebo canary deployment stratégie
• Schopnosť rollbacku v priebehu minút, nie hodín

5. Transparentná incident komunikácia

Výpadok ESKN ukázal, že rovnako dôležitá ako technická odolnosť je komunikácia:

• Status page v reálnom čase (nie FB post o 3 hodiny)
• Jasné SLA s definovanými časmi odozvy
• Post-incident report s root cause a nápravnými opatreniami
• Pravidelné záťažové testy, nie len pred spustením, ale aj počas prevádzky

Č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 tom, že súkromný sektor má priamu finančnú motiváciu minimalizovať výpadky. 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 aplikovať overené inžinierske princípy.

My sme to vyskúšali na vlastnej koži. Pri jednom projekte pre štátnu inštitúciu sme navrhli architektúru s automatickým failoverom. Klient najprv nevidel zmysel v 'duplikovaní' infraštruktúry. Po prvom výpadku AWS regiónu, keď ich systém bežal ďalej, sa diskusia skončila.

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

Výpadky štátnych e-služieb nie sú nevyhnutnosť. Sú dôsledok 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ť.