A ticket site sits idle for weeks and then takes a year of traffic in ninety seconds. Only one of those two states is worth engineering for.
The load is not a high average. It is every buyer arriving in the same second, already signed in and ready to write.
Tell us the on-sale timestamp and we scale ahead of it rather than reacting to it, because autoscaling triggered by load is already half a minute late by the time the queue has formed.
Ticket rows are locked at the database rather than checked in application code, so two people clicking the same seat in the same millisecond cannot both be told it is theirs.
Once concurrency passes what checkout can serve, buyers are held in an ordered waiting room and admitted in turn — slower for them, but nobody is shown an error page.
Rate limiting and challenge rules run at the edge before WordPress loads, so scripted buyers do not consume the inventory you meant for real ones.
Abandoned baskets release their seats on a platform timer rather than a visitor-triggered cron, so unsold inventory returns to the pool even at four in the morning.
During an on-sale the only question is whether checkout is keeping up. Numbers gathered afterwards are an autopsy rather than an answer.
Every request in an on-sale is a write, and writes cannot be cached. What decides the outcome is how many of them the database will accept at once.
These are the settings that differ from a standard WordPress site on the same plan. Each one exists because demand arrives at a timestamp you already know.
| Setting | What we do | Why |
|---|---|---|
| Capacity | Scaled ahead of an announced on-sale rather than in response to load | Reactive autoscaling begins provisioning after the queue has already formed, which is the wrong half of the minute. |
| Full-page cache | Bypassed on basket, checkout and seat-selection URLs | A cached seat map shows the seats that were free when it was generated, which is precisely how a site oversells. |
| Ticket inventory writes | Row-level locks with a short lock timeout | Two buyers reaching the same seat in the same millisecond must not both receive a confirmation email. |
| Basket expiry | Platform timer, independent of site traffic | Held seats have to return to the pool overnight, when there is nobody on the site to trigger a cron run. |
| Edge rate limiting | Per-IP and per-session challenge rules ahead of PHP | Scripted buyers absorb both allocation and worker capacity that was meant for the queue behind them. |
Every plan includes free migration, daily backups, SSL and 24/7 support.
Free migration, capacity scheduled to the minute, and inventory that cannot be sold twice.