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

The electronic land registry (ESKN) outage in January 2026 once again highlighted a long-standing problem in Slovak public administration – the fragility of critical e-services. Real estate agencies, notaries, and lawyers couldn't work. Citizens couldn't verify property ownership. The Geodesy Authority communicated reluctantly and vaguely. Hands up if you're surprised. Nobody? Exactly.

This isn't the first or last such outage. But it's an opportunity to look at what should be done differently.

Why State Systems Fail

Most critical state systems in Slovakia were built in an era when cloud, containerization, or microservices were just dreams. Typical problems include:

• Monolithic architecture, one component fails and the entire system goes down
• No redundancy, the system runs on a single server or in a single data center
• Outdated technology – Systems built on technologies that no longer have support
• Vendor lock-in – Dependence on a single supplier with no incentive to modernize

Architecture Principles for Reliable e-Services

1. Design for Failure

Every system component can fail – and the system must account for that. This means:

• Circuit breakers between components
• Graceful degradation instead of complete outage
• Automatic failover to backup instances

2. Observability from Day One

You can't fix what you can't see. Modern systems need:

• Centralized logging – All logs in one place, searchable
• Real-time metrics – CPU, memory, response time, error rate
• Distributed tracing – Ability to track a request across components
• Alerting – Automatic notifications before users notice problems

3. Scalability and Redundancy

Critical services must run in at least two independent environments:

• Multi-zone or multi-region deployment
• Load balancing between instances
• Database replication with automatic failover

4. Automated Deployment and Rollback

Manual deployment is a recipe for disaster:

• CI/CD pipeline with automated tests
• Blue-green or canary deployment strategies
• Ability to rollback within minutes, not hours

5. Transparent Incident Communication

The ESKN outage showed that communication is as important as technical resilience:

• Real-time status page (not a Facebook post 3 hours later)
• Clear SLAs with defined response times
• Post-incident reports with root cause and corrective actions
• Regular load tests, not just before launch, but also during operation

What We Can Learn from the Private Sector

Banks, e-shops, and SaaS companies face the same challenges, and most of them have already solved them. The difference is that the private sector has direct financial incentive to minimize downtime. The public sector lacks this feedback loop.

The solution isn't for the state to buy more expensive technology. It's to start applying proven engineering principles.

We learned this firsthand. On one project for a state institution, we designed an architecture with automatic failover. The client initially didn't see the point of 'duplicating' infrastructure. After the first AWS region outage, when their system kept running, the discussion was over.

When we build a system, we think about what happens when something fails, because something always fails, it's just a question of when.

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

If you're building a system that needs to be reliable, let's talk about how to achieve that.