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

An e-service proves its reliability when a dependency fails or data needs restoring. An outage notice alone does not establish a technical cause. The guidance below draws on the AWS reliability principles rather than on any technical investigation of one ESKN incident, which nobody outside the operator can honestly perform.

Where to look for risk

Review dependencies and supported versions. Then find out whether anyone has ever restored from the backups. A monolith is not inherently unreliable. The risk is a failed dependency that stops the entire process while the fallback exists only in a document that nobody has executed since the system went live.

Architecture principles for reliable e-services

Design for Failure

Every component fails eventually. A circuit breaker cuts off a hanging dependency so one slow service doesn't drag the rest down with it, and graceful degradation keeps whatever still works usable instead of serving a blank page, which is the version users remember. 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

Choose redundancy and replication around acceptable downtime and data loss. Multiple environments limit the impact of failure only when their dependencies are genuinely independent and the spare capacity survives losing half of it without a queue building up. Failover still has to be tested on a schedule.

Automated deployment and rollback

Repeatable deployments and automated checks reduce mistakes. Blue-green and canary releases allow gradual verification, but the rollback is the part worth rehearsing, especially with database changes, where reverting the application code may not restore compatibility at all.

Transparent communication during an outage

During an outage, name the affected functions and the time of the next update. Explain any available workaround. Confirm a cause only after investigation, then publish the impact and corrective actions after recovery.

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

Demonstrate recovery

Both public bodies and private companies need an incident decision-maker and a restoration order. A recovery exercise should produce measured recovery time and evidence that the restored data is complete.

Exercise failover with a controlled switchover under an agreed load. Measure recovery time against the objective. A backup environment alone does not establish those results.

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