On election day 2024, citizen information portals, results reporting systems, and voter services experienced traffic spikes of 50-100x their normal baseline. Systems designed for average load went down. Systems designed for peak load stayed up but cost 100x more than necessary for 364 days of the year. The systems that performed best were those designed for elasticity—the ability to scale rapidly when needed and scale down when not.

The spike pattern. Government digital services face predictable spikes: tax filing deadlines, enrollment periods, election days, and emergency response events. These are not black swans—they are calendar events. The system knows, months in advance, when the next spike will occur.

Designing for elasticity. Elastic design requires three components: a scaling layer that can provision resources in minutes (not hours), a stateless application architecture that allows horizontal scaling without session affinity, and a data layer that can absorb write spikes without degradation. The scaling layer is a cloud auto-scaling group or a Kubernetes HPA. The stateless application requires careful session management—externalizing state to Redis or a distributed cache rather than local memory. The data layer requires write buffering, connection pooling, and read replicas that can be promoted under load.

The procurement challenge. EU government tenders on TED typically specify capacity requirements in fixed terms: "the system must support 10,000 concurrent users." This specification misses the point. The system must support 10,000 concurrent users for 4 hours on election day and 200 concurrent users for the rest of the year. Procurement that specifies peak capacity without specifying the cost structure for baseline operations leads to over-provisioned, expensive systems.

The SAM.gov parallel. US federal cloud procurement through SAM.gov increasingly references cloud elasticity requirements, but the evaluation criteria often weight static capacity metrics over dynamic scaling capabilities. Bidders who can demonstrate elastic architecture—auto-scaling policies, load test results at 10x baseline, and cost models that show baseline spend—win on both performance and price.

Election-grade infrastructure is not about building for the worst case. It is about building for the transition—the ability to shift from baseline to peak and back without manual intervention, without data loss, and without breaking the budget.