Events and ticketing, built for the ninety seconds an on-sale actually lasts.

What a unit of inventory actually is

A reserved seat in a named row, a place in an unnumbered zone, a general-admission capacity count and a timed-entry slot are four different inventory models. Most platforms need more than one, and a system built around only reserved seating cannot represent a standing floor without a rewrite.

Seat maps are the part that looks simple and is not. A venue changes configuration between a concert and a conference, restricted-view seats need marking, accessible positions have companion rules, and holds for the promoter, the artist and the venue come out of inventory before a single ticket goes on sale.

Get this wrong and every later feature inherits the error, because pricing, entry validation and settlement all reference the unit you defined here.

Holds, concurrency and the checkout clock

The moment a customer selects a seat it has to become unavailable to everyone else, for a bounded time, atomically. That is the whole problem. A hold that is advisory rather than authoritative produces double sales under load, and load is exactly when it matters.

The clock is a product decision with a technical consequence. Too short and customers lose seats while entering card details; too long and inventory is starved during the only minutes that matter. Expiry has to be reliable rather than best-effort, because a hold that never releases is inventory destroyed.

Group bookings and split payment complicate this further: several people paying for one held set of seats, where a partial failure must not leave a group half-ticketed.

Payments, fees and the refund path

Several gateways rather than one, because a failed processor during an on-sale is lost revenue that does not come back and the event only goes on sale once. Routing between them has to be automatic rather than a configuration change made by someone who is awake.

Fee structure is more intricate than it appears: booking fees, venue fees, payment surcharges and taxes that differ by territory, some shown at selection and some at checkout, with rules about what may be advertised as the price. The breakdown has to survive into settlement, because each component belongs to a different party.

Refunds deserve design rather than an afterthought. A cancelled event means thousands of refunds at once, against payments made weeks earlier across several gateways, and the platform that handles it by hand will spend a fortnight doing so.

Entry validation that works when the network does not

Gate connectivity is unreliable at exactly the venues where crowds are largest. Scanning has to work offline, deduplicate when devices reconnect, and never admit the same ticket twice across two scanners that could not see each other for twenty minutes.

Ticket security matters here. A static barcode screenshotted and shared is the most common fraud in the sector, and rotating codes bound to a device are the usual answer, with a documented fallback for the customer whose phone is dead at the gate.

Settlement to venues, promoters and partners

The money arrives in one account and belongs to several parties. Each sale splits between the venue, the promoter, any co-promoter, the platform fee and tax, and each partner needs a statement they can reconcile without asking you for an export.

Timing is a commercial decision with a cash consequence. Paying out before an event has happened exposes you to cancellation; paying out long after damages the partner relationship. Whichever you choose, the ledger has to hold the obligation clearly in the interval.

Discovery, loyalty and shaping demand

Between on-sales, the platform is a discovery product. Browse, search, recommendations and reminders decide whether a customer who came for one show finds a second, and that repeat rate is what separates a ticketing business from a payment page.

Loyalty in this sector works when it buys access rather than discount: presales, better seats, priority in the queue. A tiered programme built on entitlements is worth considerably more to a customer than a points balance, and costs the operator less.

Load readiness, then the on-sale

The platform gets tested at a hundred times its normal traffic, at a moment announced publicly in advance, with no possibility of postponing. Load testing here is not a checkbox; it is a rehearsal of the exact minute, including the waiting room, the queue fairness rules and the behaviour when a gateway degrades.

What matters most is graceful failure. Under extreme load the platform should slow down and hold the line on correctness rather than speed up and sell a seat twice. That trade-off is decided in the architecture, not on the night.