Der Ausfall des elektronischen Katasters (ESKN) im Januar 2026 hat erneut ein langjähriges Problem der slowakischen öffentlichen Verwaltung deutlich gemacht. Kritische E-Services sind fragil. Immobilienbüros, Notare und Anwälte konnten nicht arbeiten. Bürger konnten Eigentumsverhältnisse nicht überprüfen. Das Amt für Geodäsie kommunizierte zögerlich und vage. Wer überrascht ist, hebe die Hand. Niemand? Genau.
Das ist nicht der erste und nicht der letzte Ausfall dieser Art. Aber es ist eine Gelegenheit, sich anzusehen, was anders gemacht werden sollte.
Warum staatliche Systeme ausfallen
Die meisten kritischen staatlichen Systeme in der Slowakei entstanden in einer Zeit, in der Cloud, Containerisierung oder Microservices noch Träume waren. Man sieht es ihnen an. Sie sind Monolithen, deshalb reißt eine ausgefallene Komponente das ganze System mit. Sie laufen auf einem einzigen Server oder in einem einzigen Rechenzentrum, deshalb gibt es nichts, worauf man umschalten könnte, wenn genau dieses ausfällt.
Dazu kommt das Alter. Ein Teil dieser Systeme basiert auf Technologie, die niemand mehr unterstützt, sodass eine bekannte Schwachstelle nie einen Patch bekommt. Und wenn nur der ursprüngliche Anbieter den Code versteht, hat der Staat niemanden, gegen den er die Modernisierung ausschreiben könnte.
Architekturprinzipien für zuverlässige E-Services
Design for Failure
Jede Komponente fällt irgendwann aus, und das System muss von vornherein damit rechnen. Ein Circuit Breaker trennt eine hängende Abhängigkeit ab, damit ein langsamer Dienst nicht den Rest mit hinunterzieht. Graceful Degradation hält das, was noch funktioniert, nutzbar, statt eine leere Seite auszuliefern. Und ein automatisches Failover verlagert den Verkehr auf eine Standby-Instanz, ohne dass jemand nachts ans Telefon muss.
Observability vom ersten Tag an
Sie können nicht reparieren, was Sie nicht sehen. Ein modernes System braucht vier Dinge gleichzeitig:
- alle Logs an einem Ort und durchsuchbar
- Echtzeit-Metriken, also CPU, Speicher, Response Time und Error Rate
- Distributed Tracing, damit sich eine einzelne Anfrage über Komponenten hinweg verfolgen lässt
- Alerting, das anschlägt, bevor der erste Nutzer das Problem meldet
Ohne sie wird die Ursachensuche bei einem Ausfall zum Raten.
Skalierbarkeit und Redundanz
Ein kritischer Dienst muss in mindestens zwei unabhängigen Umgebungen laufen. Praktisch heißt das Deployment über mehrere Zonen oder Regionen, Load Balancing zwischen den Instanzen und eine Datenbankreplikation, die im Ausfall selbst auf eine Replik umschaltet. Brennt ein Standort, läuft der Verkehr anderswo weiter.
Automatisiertes Deployment und Rollback
Manuelles Deployment ist ein Rezept für eine Katastrophe. Eine CI/CD-Pipeline mit automatisierten Tests fängt den Fehler ab, bevor die Bürger ihn finden. Blue-Green- und Canary-Strategien schicken eine neue Version zuerst auf einen kleinen Teil des Verkehrs. Und wenn trotzdem etwas kaputtgeht, soll die Rückkehr zur vorherigen Version Minuten dauern, nicht Stunden.
Transparente Kommunikation während eines Ausfalls
Der ESKN-Ausfall hat gezeigt, dass Kommunikation ebenso wichtig ist wie technische Resilienz. Eine Echtzeit-Statusseite sagt den Leuten, woran sie sind. Ein Facebook-Post drei Stunden später tut das nicht. Ein SLA mit definierten Reaktionszeiten gibt dem Versprechen Gewicht, und nach dem Incident sollte ein Bericht folgen, mit der Ursache und dem, was sich ändert, damit er sich nicht wiederholt.
Lasttests gehören übrigens nicht nur vor den Start. Der Verkehr verändert sich mit der Zeit, also muss das Testen mitwachsen.
Was wir vom privaten Sektor lernen können
Banken, Onlineshops und SaaS-Unternehmen stehen vor denselben Herausforderungen, und die meisten haben sie bereits gelöst. Der Unterschied liegt im Anreiz. Der private Sektor zahlt für jede Minute Ausfallzeit direkt. Der öffentliche Sektor bekommt diese Rechnung nie.
Die Lösung besteht nicht darin, dass der Staat teurere Technologie kauft. Sie besteht darin, bewährte Engineering-Prinzipien anzuwenden.
Und ein Failover ist kein Beweis für Resilienz, nur weil es in einem Architekturdiagramm auftaucht. Es muss regelmäßig mit einer kontrollierten Umschaltung geprobt, gegen ein Wiederherstellungsziel gemessen und unter realistischer Last überprüft werden.
Wenn wir ein System bauen, denken wir auch daran, was passiert, wenn etwas ausfällt. Etwas fällt immer aus. Die Frage ist nur, wann.
Ausfälle staatlicher E-Services sind nicht unvermeidlich. Sie sind das Ergebnis von Architekturentscheidungen oder deren Fehlen. Prinzipien, die im privaten Sektor funktionieren, funktionieren auch im öffentlichen. Jemand muss nur anfangen, sie anzuwenden.
Wenn Sie ein System bauen, das zuverlässig sein muss, sprechen wir darüber, wie sich das erreichen lässt.