Context
A public body publishes first-come-first-served funding calls: applications open at an exact moment and the budget runs out within minutes. Applicants prepare their file for weeks and stake it all on that window.
Problem
A click day compresses months of traffic into minutes. Everyone arrives in the same second, authenticates through the Italian digital identity system and uploads attachments. A single-server setup cannot absorb that spike, and a failure inside the window cannot be recovered, because the call does not run twice and lost applications become a legal problem before a technical one. The platform had to take the wave, and it had to be proven to take it before opening day.
What I built
The application platform with digital identity login, submission handling and attachments, together with the Kubernetes infrastructure that absorbs the peak. Separate autoscaling for web and workers, Redis queues with Horizon, and worker scaling driven by a purpose-written Prometheus metric on queue depth: processes grow when the queue grows, not when the processor notices. I set up load testing with Artillery on a realistic authentication scenario, with latency and error thresholds agreed before the runs.
Outcome
Built for the spike: workers scale from 80 to 120 processes in seconds, and the load was tested at 150 requests per second before the call opened. That figure comes from load tests, not from production traffic.