Peak concurrency in the first minutes of an on-sale is the number that decides whether a sale succeeds or fails. Many organisations still size their systems by total tickets, but selling five thousand tickets spread over three days and selling five thousand in fifteen minutes are entirely different engineering problems.
Why the peak collapses into a few minutes
Buyers know the on-sale time and all want the good seats. They keep the page open, refresh repeatedly, and when the clock strikes they all send requests within seconds. Social channels and supporter groups sharpen the effect, because the time is repeated everywhere.
The traffic curve is therefore not a gentle hill but a spike. Most publicly visible ticketing failures happen in the first fifteen minutes.
The three points that break most often
The first is the application tier, where requests exceed available workers. The second is the database, particularly the temporary hold taken when several buyers select the same seat. The third sits outside direct control: the payment gateway, which has its own transactions-per-second ceiling.
| Bottleneck | Symptom | Response |
|---|---|---|
| Application tier | Pages slow, then time out | Scale horizontally, add a waiting room |
| Database | Seat selection returns conflicts | Time-bound holds, split reads and writes |
| Payment gateway | Success rate drops | Pace requests, agree limits in advance |
A waiting room is a tool, not a failure
Many organisations resist a waiting room for fear of annoying buyers. The opposite holds in practice: a queue that shows a position and an estimated wait is far easier to accept than a blank page or an unexplained error.
A waiting room also protects the sale itself. It keeps inbound requests within the tested threshold rather than letting everything arrive at once and take the system down.
Rehearse before the real on-sale
Load testing is only worth anything when it mirrors real behaviour: many people arriving in the same minute, choosing the same desirable block, paying at the same time. A test that spreads requests evenly over an hour produces a pretty and useless result.
Alongside the technical test, run an operational rehearsal: who watches the dashboard, who contacts the payment provider when the success rate drops, who decides to pause the sale. Agreeing this in advance saves searching for people when it matters.
Frequently asked questions
How do we estimate peak concurrency
The practical method is to look at the last on-sale and at channel engagement numbers. Without history, take the ticket count of the most popular block, multiply by an interest factor, and test above the estimate.
Should we split the sale into waves
Yes; it is the most effective way to cut the peak without spending on infrastructure. Split by price tier, by stand, or by membership group, as long as it is published clearly from the start.
How far ahead should preparation finish
Load testing and rehearsal should be complete at least a week before the on-sale, leaving time to fix what the test exposes.
Conclusion
A smooth on-sale is not luck; it comes from knowing the peak number in advance and having run above it. If an upcoming event risks a sharp peak, talk to the KHC team about the waiting-room design and the rehearsal schedule.
See also the four KHC deployment packages.
QR tickets, gate scanning and same-night reconciliation.
