When State e-Services Go Down: Architecture Principles for Reliable Public Systems

The electronic land registry (ESKN) went down in January 2026, and with it went a working week for everyone who depends on it. Real estate agencies, notaries, and lawyers were stuck. Citizens couldn't verify who owned what. The Geodesy Authority said little, and said it slowly. Hands up if you're surprised. Nobody? Right.

This isn't the first outage of its kind and it won't be the last. But it is a good moment to ask what should be done differently.

Why state systems fail

Most of Slovakia's critical state systems were designed when cloud, containerization, and microservices were still somebody's slide deck. It shows. They are monoliths, so one failing component takes everything with it. They run on a single server or in a single data center, so when that one goes, there is nowhere to fail over to.

Age compounds the problem. Some of these systems sit on technology nobody supports anymore, which means a known vulnerability never gets a patch. And when only the original supplier understands the code, the state has nobody to put the modernization work out to tender against.

Architecture principles for reliable e-services

Design for Failure

Every component fails eventually, and the system has to assume it. A circuit breaker cuts off a hanging dependency so one slow service doesn't drag the rest down with it. Graceful degradation keeps whatever still works usable instead of serving a blank page. Automatic failover moves traffic to a standby instance without anyone answering a phone at 3am.

Observability from day one

You can't fix what you can't see. A modern system needs four things at once:

• every log in one place, and searchable
• real-time metrics, meaning CPU, memory, response time, and error rate
• distributed tracing, so a single request can be followed across components
• alerting that fires before the first user reports the problem

Without them, finding the cause of an outage is guesswork.

Scalability and redundancy

A critical service has to run in at least two independent environments. In practice that means deploying across zones or regions, load balancing between instances, and database replication that promotes a replica on its own. One site burns, traffic carries on somewhere else.

Automated deployment and rollback

Manual deployment is a recipe for disaster. A CI/CD pipeline with automated tests catches the mistake before citizens do. Blue-green and canary strategies send a new version to a slice of traffic first. And when something breaks anyway, getting back to the previous version should take minutes, not hours.

Transparent communication during an outage

The ESKN outage showed that communication matters as much as technical resilience. A real-time status page tells people where they stand. A Facebook post three hours later does not. An SLA with defined response times puts weight behind the promise, and once the incident is over a report should follow with the root cause and what changes so it doesn't happen again.

Load testing, by the way, doesn't belong only before launch. Traffic changes over time, so the testing has to change with it.

What we can learn from the private sector

Banks, e-shops, and SaaS companies face the same challenges, and most have already solved them. The difference is incentive. The private sector pays for every minute of downtime directly. The public sector never gets that bill.

The answer isn't for the state to buy more expensive technology. It's to apply engineering principles that already work.

And failover is not proof of resilience just because it appears in an architecture diagram. It has to be exercised on a schedule with a controlled switchover, timed against a recovery objective, and checked under load that resembles the real thing.

When we build a system, we think about what happens when something fails. Something always fails. The only question is when.

State e-service outages are not inevitable. They are the result of architectural decisions, or the absence of them. Principles that work in the private sector work in the public sector too. Someone just has to start applying them.

If you're building a system that has to stay up, let's talk about how to get there.