An auction marketplace kept its site up through record bidding days with edge caching and load shedding

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Used farm and construction machinery changes hands through timed online auctions here — sellers list lots with photos and inspection reports, buyers bid from phones in fields and workshops. Closing minutes are the product: serious bidders wait until the last moments to commit. The operation is lean, run by a handful of staff with a third-party auction engine handling the bidding itself, and revenue depends on sellers believing their auction's closing hour will work. The front end and infrastructure are the marketplace's own; the bidding core is not.

What it was costing

Closing minutes of popular auctions drove bidding storms that overwhelmed the origin — bidders saw spinners exactly when it mattered, the marketplace's reputation took the blame, and the last big auction's final hour was effectively down.

What they could see

• During a flagship auction's final hour, bids spun and failed while watchers refreshed — down when it mattered.
• Bidders reported stale or missing bid history in closing minutes, and some stopped bidding early as a result.
• The origin server maxed out while the rest of the site stayed oddly fast — the bottleneck was invisible to staff.
• Sellers started asking what happens if my closing hour is busy — a question nobody could answer with confidence.
• Support tickets after big closings read the same way: tried to bid, it spun, gave up.

The constraints we worked inside

• Bidding itself must never be cached or delayed; the architecture must separate hot reads from the write path.
• The auction engine is third-party; the marketplace controls the front end and edge, not the bidding core.
• Sellers schedule auctions with no traffic forecast; protection must be always-on, not switched on per event.

What had been tried before

The origin VPS was upgraded to the provider's largest instance before the last record auction.

A bigger box still serialized the write path — closing-minute bids queued behind each other while reads starved them; the ceiling moved, the failure shape didn't.

A front-end caching plugin was installed on the marketplace site to absorb reads during popular closings.

It cached bid history too aggressively; bidders saw stale prices, support tickets spiked mid-auction, and the plugin was pulled before the weekend ended.

The auction engine vendor's own throttling was enabled for closing windows on their advice.

Throttle responses looked identical to failures from the bidder's side, so people retried and multiplied the load — and legitimate sniping software abandoned closings entirely.

What we proposed

We proposed separating hot reads from the write path: lot pages, photos, and bid histories cache at the edge with short TTLs and hard cache-bypass on bid actions, so closing-minute readers consume edge capacity while the third-party bidding core receives a leaner, steadier write load. A waiting-room rule queues overflow per lot closure, so the core processes bids in order instead of drowning in simultaneous retries. Dashboards on origin saturation and bid latency would alert before the crowd notices, with thresholds tuned against recorded closing storms rather than guesses.

Just as important is what we ruled out, and why:

• Re-engineering the third-party auction core — The bidding engine belongs to a vendor; the marketplace controls the front end and edge only, so the fix had to live where we actually hold the levers.
• Provisioning origin capacity for record days — Sellers schedule auctions with no traffic forecast; paying every day for the biggest closing hour of the year is the bill the marketplace already couldn't justify.
• Rate-limiting bid endpoints at the edge — Closing-minute snipers are the most valuable bidders on the platform; rejecting them protects the origin by discarding exactly the revenue the closing exists to produce.

How the work ran

Delivered by the systems pod — engineer over 6 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Cloudflare

Capacity at the edge scales with the storm while the origin stays lean — the marketplace controls the edge, not the third-party bidding core.

Edge caching

Short-TTL lot pages and photos serve closing-minute readers from the edge, so reads stop competing with the write path when it matters most.

Waiting-room rules

Queuing overflow per lot closure processes bids in order — shedding beats rejecting, and no bidder sees an error page during a storm.

Origin monitoring

Saturation and bid-latency alerts fire before the crowd notices, buying minutes to act instead of hours of complaints to answer afterward.

Cache-bypass write path

Bid actions never cache or queue behind reads — the one request class where any delay is unacceptable and every millisecond is visible to bidders.

What went wrong

How we worked together

Cadence

A mid-week working call with the operations lead, full-day availability during the first two protected closings, and a same-day post-mortem note after every closing.

Client side

The operations lead owned the closing calendar and joined the first storm rehearsals; a part-time contractor handled seller communications about the changes.

Decisions

Threshold and queue settings were tuned from recorded data and confirmed in writing before each weekend; the operations lead held veto on anything bidder-visible.

They provided

Recorded logs from three past closing storms, staging access mirroring production, and seller-facing copy review from the operations lead.

What changed

The headline: highest-closing-day volume in the marketplace's history served without bidder-visible errors — Closing-hour outages → clean record auctions, read from Auction-day monitoring. A second check: origin requests during closing storms at −88%.

Closing hour turned from a reputational liability into a selling point — the operations lead plays recorded closing storms in seller conversations as proof the platform holds. Staff watch dashboards instead of refreshing the site themselves, and the support inbox on auction days reads like ordinary business. Bidders stopped asking whether the marketplace would survive the final minutes. The team's week no longer contains a standing dread keyed to whatever lots close on Saturday night.

The result was read from Auction-day monitoring against the pre-engagement baseline over the stated window, with a guardrail check on origin requests during closing storms. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A closing-storm rehearsal script replaying recorded traffic against staging before big weekends.
• Waiting-room threshold documentation: current values, how they were derived, when to revisit.
• Origin-saturation and bid-latency dashboards with alert routing to the operations lead.
• An auction-day runbook covering queue behavior, escalation, and seller communications.