Cloud for Traffic Spikes: Getting a Ticketing System Ready for Its Busiest Minute
Picture a system that serves almost nobody all week, then in one particular minute has to serve tens of thousands of people simultaneously. That is the workload profile of football match ticket sales, and it is why cloud for traffic spikes is a serious topic in this industry.
One thing sets this challenge apart from other systems. There is no second chance. If the system stumbles in the minute tickets open, the failure happens in front of tens of thousands of supporters and becomes a public conversation immediately. Not the sort of thing you quietly patch in the next release.
PT Awan Dinata Teknologi came to us with that problem.
Where they stood before working with Casa5
The entire platform ran on hardware they owned, in a physical location.
Worth stressing: this was not a bad setup. The team behind it already practised mature engineering. The problem was never the quality of the design. It was the limitations baked into a physical foundation.
Capacity has to be bought for the busiest day
Hardware was procured against the highest traffic that might occur. Which means that outside ticket release days, most of that capacity sat idle. And was still paid for.
There is no button for adding capacity right now
When a spike arrived larger than expected, nothing could be done in the moment. Adding capacity meant procurement, installation, and weeks of waiting.
Resilience is difficult and expensive
Building a fallback layer on physical infrastructure means doubling the hardware bill. For many companies, that risk simply ends up carried and quietly hoped against.
Every component is maintained in-house
Databases, queueing, storage, the caching layer, all of it became the internal team’s maintenance responsibility. Time spent there is time not spent improving the experience of people buying tickets.
Designing cloud for traffic spikes: how Casa5 approached it
We were firm about one thing from the outset. This was not simply relocating a system. It was a cloud adoption journey.
The distinction matters. Moving things across as-is only reproduces the same problems in a new place, with capacity still rigid and maintenance still manual. Cloud adoption means replacing the components you have been nursing yourself with managed services, so the operational load genuinely transfers.
Three goals agreed at the start
- Capacity that follows demand rather than capacity guessed in advance
- Resilience built in as standard rather than treated as a separate project
- Cost reviewed from zero, hunting for more efficient alternatives without giving up performance or security
There was one longer-term goal as well: preparing the foundation to carry AI-based capabilities later.
Those three goals are what shaped the final design. Cloud for traffic spikes only works if the elasticity is actually used, not merely available.
What we chose not to change was also a decision
We deliberately preserved how the team releases and monitors their systems.
Big change belongs in the foundation layer, not in an engineering team’s daily habits. A transformation that forces everyone to relearn their job from scratch carries a much higher chance of stalling halfway.
Performance testing as a pass condition
For a ticketing system, confirming that things work is not enough. The project was declared ready only after passing functional testing, security testing, and performance testing.
Backups and alerting inside the definition of done
Not follow-up work scheduled for some later date, but part of what had to be complete before handover.
The whole sequence was finished in three weeks.
Before and after: what genuinely changed
| Area | Before | After working with Casa5 |
|---|---|---|
| Facing a ticket release | Resting on fixed capacity bought up front | Capacity grows automatically with the spike, then shrinks back |
| Capacity outside match days | Idle, still paid for | Matches actual usage |
| Cost structure | Capital spend on hardware up front | Operating cost that follows usage |
| Service resilience | Expensive to achieve, often carried as risk instead | Spread across more than one location as standard |
| Maintenance load | Every component nursed in-house | Shifted to managed services |
| How the team works | Already mature | Left intact, no relearning required |
| Readiness to innovate | Capped by physical hardware | Ready to carry AI-based capabilities next |
What was left behind
The biggest change for PT Awan Dinata Teknologi is not about the technology. What disappeared was a recurring worry that used to arrive every time tickets opened.
Previously, each release was a gamble: is the capacity we prepared enough? That question is no longer relevant, because capacity now follows demand.
Cost shifted from a large payment up front to spend proportional to usage. For comparison, a similar shift happened with our commerce client in the cloud migration without downtime case study, though the trigger was different. And the team hours once spent nursing hardware went back where they belong, which is improving the experience of supporters buying tickets.
As with our other engagements, a partner funding programme combined with Casa5’s investment meant the professional services cost to the client was zero.
Questions we get asked
Why do servers crash when ticket sales open? Because the capacity is fixed and the demand is not. A system that is perfectly adequate on a normal day can be overwhelmed within seconds when tens of thousands of people arrive together.
Does moving to the cloud automatically solve traffic spikes? It does not, and this gets misunderstood often. The cloud provides the capability, but the architecture has to be designed to use it. An application moved across untouched will still stumble.
Is the cloud always cheaper? Not always, and we never promise that at the outset. What changes is the shape of the cost, from paying up front for peak capacity to spending in line with usage. For workloads with extreme spike patterns, that shift usually does end up cheaper.
Extreme spike patterns are not unique to ticket sales. Flash sales, simultaneous registration windows, and limited product drops all share the same character. Casa5 designs cloud infrastructure that is elastic and economical for exactly that pattern. Tell us what you need through our contact page.
No comment