Auction hosting built for the final thirty seconds.
An auction site is quiet for six days and then decides everything in half a minute. That half minute is the only part worth engineering for.
Everything happens at once, on purpose.
Auction traffic is not a curve. It is a wall at a scheduled moment, and the site has to be correct as well as fast.
Two bids in the same instant
Sniping means simultaneous writes against the same item. Bid handling is set up so the second bid reads the first rather than both being accepted at the same price.
Auctions that close on schedule
A lot ending at eight must end at eight, not on the next page view. Closing runs on a real system scheduler rather than on traffic, so an unvisited auction still closes.
Current price, never a cached one
An item page shows a number that changes by the second. Those pages are excluded from the page cache entirely, because a cached bid is a wrong bid.
Watchers all arriving together
Everybody who watched a lot opens it in the last minute. Capacity is planned around the close time rather than the daily average, which is meaningless here.
A record of every bid
Disputes are settled from history, so bid records are retained and backed up rather than trimmed when the table grows.
Fast is not enough if the price is wrong.
Most performance advice is about serving the same thing to more people. An auction is the opposite: the answer changes constantly and being slightly out of date is being wrong.
- Concurrent bids resolved without lost writes
- Auction close driven by system cron
- Item pages excluded from the page cache
- Full bid history retained
The last minute is the benchmark.
Average response time on an auction site tells you nothing. What matters is response time while hundreds of people bid on the same lot at once.
What we change for auction sites
Every row exists because the site has to be right under contention, not merely quick when it is quiet.
| Setting | What we do | Why |
|---|---|---|
| Bid writes | Serialised per lot so no two land at the same price | Sniping produces genuinely simultaneous writes against one row, and without ordering the second bidder overwrites the first at an identical amount. |
| Auction closing | Driven by system cron rather than page views | WordPress's scheduler only fires when somebody visits, so a lot with no watchers in its final minutes simply never ends. |
| Item pages | Excluded from the page cache without exception | The current bid changes by the second, and a cached figure is not stale content - it is a price somebody will act on. |
| Capacity planning | Sized for the closing window, not the daily mean | Everyone who watched a lot arrives in its last sixty seconds, so the average tells you nothing about the only moment that matters. |
| Bid history | Retained in full and included in backups | Disputes are settled by showing exactly who bid what and when, so trimming the table to keep it small destroys the record it exists for. |
Simple, transparent pricing.
Every plan includes free migration, daily backups, SSL and 24/7 support.
- 1 WordPress site
- 10 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Support tickets
- 5 WordPress sites
- 50 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Priority support tickets
- 20 WordPress sites
- 200 GB NVMe disk
- Free SSL
- Daily backups
- One-click deployment
- Dedicated support
Questions, answered.
Can two bids collide and one be lost?
Why do my auctions not end on time?
Can auction pages be cached at all?
How much traffic should I plan for?
Win the last thirty seconds.
Move the auction site across - migration is free, bid history included.