Challenges
A ticket on-sale is not steady traffic. When Frontier Touring put the Australian leg of Taylor Swift’s Eras Tour on sale, two days carried the equivalent of an entire month’s traffic — and it arrived as a spike, not a curve.
At peak the platform was taking 15 user registrations per second and 850 dynamic content requests per second — the kind of request that cannot be served from cache at every level. Anything origin-bound in that path becomes the thing that ends the sale. So does any single point of failure: one saturated node, one uncached template, one queue with no admission control.
Frontier also could not trade availability for experience. The people in that queue were buying, not browsing.
Core dna Solution
Take as much of the spike off the origin as possible, then meter what is left.
Multi-layered caching. Caching sits at every level of the request lifecycle — CDN, web server, and application/database — so when one layer cannot serve a response, the next one can. The CDN fronts the entire application stack rather than just static assets, serving dynamic content as well, and terminates SSL at the node instead of at the origin.
Dynamic scaling. Backend capacity follows demand rather than being provisioned for an average that a tour on-sale ignores.
A waiting room. Admission to the purchase path is metered, so the queue is a designed experience rather than a timeout.
Together these let the platform serve thousands of simultaneous requests while load times stayed fast.
Results
570,000 tickets sold. No downtime. Load times and reliability held through the entire peak — across two days that carried a month’s traffic.
What's Next?
The caching, scaling and waiting-room patterns proven on this on-sale are now standard practice on Core dna — applied across client platforms rather than kept as event-day special handling.
