Resilient infrastructure for critical citizen-facing services
A public information service redeveloped from a server-and-database platform to pre-built pages on a content delivery network, now £1.2 million cheaper to own over seven years with no vendor lock-in.
Challenge
The organisation’s public information service ran on a conventional server-and-database platform, which has to be sized, paid for and patched for peak traffic that arrives only for short periods, and which can only move host by moving servers and data. The redevelopment was the opportunity to change the architecture. The organisation wanted critical citizen-facing infrastructure that cost less to own, that its own team could run and change, and that did not depend on one hosting provider.
Solution
We redeveloped the service so that the work happens at publication rather than on each request. No server or database sits on the public path, so peak traffic is handled by an edge compute and storage network, and pages keep being served even when the systems behind them are unavailable.
Publishing is separate from delivery. On a conventional platform the system that staff edit and the system the public reads are the same thing, so the moment of highest demand is also the riskiest moment to change anything, and a fault on the editing side is an outage for everyone. Here, each published update becomes a new set of files for the network to serve, so the organisation’s own team can approve and release a change during peak demand without touching what the public is reading, and no failure in the publishing system can take the public site down. The people who own the information make the changes, with an approval step and a preview, rather than waiting on a supplier or an engineer.
The system is built on open standards and open-source tooling, so it is compatible with any mainstream hosting provider and the organisation can move between hosting providers for cost or technical benefit without a rebuild.
On a conventional platform, demand works against availability: the more people ask, the closer the server is to failing. Here every request served leaves a copy at the edge for the next person, so the service is at its most available when it is busiest. That was load-tested well beyond the demand it has to meet before it went live, rather than asserted.
A LiveWyer team delivered the platform as code, with the documentation and upskilling for the organisation’s own people to operate and maintain it. The cost model moves from fixed assets to per-request pricing, where economies of scale now favour the new architecture, and non-production environments are trivial to deploy and test.
- £1.2m
- lower cost of ownership over seven years
- 100k+
- requests per second sustained in load testing
- 99.99%
- of requests answered successfully in load testing
Conclusion
The redevelopment gave the organisation a service that costs £1.2 million less to own over seven years, that its own team can change at critical times, that keeps serving when components fail, and that can change provider when it needs to. The same approach suits any public service that is read far more often than it changes.