An event platform where the busiest minute defines the architecture.
I built a purchasing and management platform for an events company. The demand is spiky: an on-sale opens and tens of thousands of people hit the same finite inventory in the same minute. I designed it so the busiest minute is the spec, not the surprise, no double-sells, no collapse at peak.
Most of the day it's quiet.
Then an on-sale opens.
Event commerce isn't a steady stream of orders. Traffic sits flat, then spikes by orders of magnitude the second tickets drop. Everything that's fine at average load breaks at peak, and peak is exactly when correctness matters most.
Everyone wants the same seats
Thousands of buyers contend for the same finite inventory in the same instant. Naive reads and writes either oversell or grind the database to a halt under lock contention.
Double-sells are unforgivable
Selling the same seat twice isn't a glitch, it's a refund, an angry customer, and a reputation hit. Allocation has to be correct under contention, not just usually correct.
The surge is the spec
If the architecture only works at average load, it doesn't work. The on-sale minute, with its thundering herd, is the real workload the system exists to survive.
Payments can't be the bottleneck
Checkout holds inventory while money moves through a third party with its own latency and failures. Hold too long and you starve other buyers; release too soon and you oversell.
Correctness under load,
then everything around it.
The platform has two halves: a purchasing path engineered for the surge, and a management side for the people running the events. I built both.
Queue & back-pressure
A virtual waiting room absorbs the on-sale spike. Buyers are admitted at a rate the core can actually serve, so load is shaped instead of dropped, and the system degrades gracefully instead of falling over.
Inventory under contention
Allocation uses short, well-scoped holds and atomic claims so a seat can be reserved by exactly one buyer at a time. No oversell, no double-sell, even when thousands hit the same inventory at once.
High-throughput checkout
The checkout path is kept narrow and fast: hold, pay, confirm. Slow and failure-prone work is pushed off the critical path so the hot loop stays fast when it's under the most pressure.
Payments without oversell
Holds are time-boxed against payment latency and expire cleanly. A failed or abandoned payment returns inventory to the pool automatically, so money and seats never drift out of sync.
The management side
Organizers create and schedule events, define capacity and allocations, set what goes on sale and when, and watch it sell in real time. The buying and managing sides share one source of truth.
Built like an owned asset
Tested, observable, and documented so it can be operated and grown, not just shipped once. This is the same standard I bring to my <a href="/services/fractional-cto">fractional CTO work</a>: build for the team that inherits it.
The decisions that
actually matter at peak.
Shape the load before it hits the core
You can't make a surge disappear, but you can decide how it arrives. Queueing and admission control turn an uncontrolled spike into a steady, serveable rate.
- →Virtual waiting room at the edge
- →Admission paced to real capacity
- →Fair ordering, no silent drops
- →Predictable behavior at the worst moment
Make allocation atomic
Correctness lives in how a seat moves from available to held to sold. I kept that transition atomic and short so contention resolves cleanly instead of corrupting state.
- →Single-owner holds
- →Time-boxed reservations
- →Automatic release on expiry or failure
- →One source of truth for inventory
Keep the hot path thin
Everything non-essential moves off the checkout critical path, so the part that runs tens of thousands of times in a minute does the least possible work.
- →Async work for anything slow
- →Idempotent operations on retries
- →Observability on the surge path
- →Graceful degradation over failure
In event commerce the architecture isn't judged on the average day. It's judged on the one minute everyone shows up at once, and it has to be correct, not just alive.
What people ask about this build.
How do you stop the same seat from being sold twice?
Allocation is atomic. Moving a seat from available to held is a single-owner operation, so exactly one buyer can claim a given seat at a time. Holds are time-boxed and release automatically if payment fails or is abandoned, so inventory and payments never drift apart, even under heavy contention.
What happens when an on-sale opens and traffic spikes?
A virtual waiting room absorbs the spike and admits buyers at a rate the core can actually serve. Instead of letting an uncontrolled surge overwhelm the database, the system shapes the load and degrades gracefully, so the busy minute behaves predictably rather than collapsing.
Does the platform also handle the organizer side?
Yes. Beyond purchasing, organizers create and schedule events, define capacity and allocations, control what goes on sale and when, and watch sales in real time. The buying and managing sides share one source of truth so capacity and inventory stay consistent.
Got a system that has to
survive its busiest minute?
High-concurrency commerce, inventory under contention, checkout that can't go down at peak, that's the kind of problem I like. Tell me what you're building.