Inventory & seat holds

Two buyers can tap “Buy” on the last ticket at the same instant. Only one of them can get it. This page explains how Blend makes that decision, for events with a simple ticket count and for events with a seat map, and, the part integrators most often get wrong, exactly when a ticket stops being available to everyone else.

General admission: one atomic compare-and-set

A general admission (GA) ticket type has three counters: availableCount (the capacity; 0 means unlimited), soldCount, and heldCount (stock the organiser has held back and is not selling). A claim for quantity tickets succeeds only when:

soldCount + quantity <= availableCount - heldCount

# availableCount of 0 means unlimited: the guard is skipped.

The important property is not the arithmetic; it is where it runs. The guard is part of the query of a single MongoDB findOneAndUpdate. The database evaluates the condition and applies the increment as one operation. There is no moment where Blend reads the count, decides, and then writes, no read-then-write window in which a second buyer can slip through.

If two buyers race for the last ticket, the database serialises the two updates. The first one satisfies the guard and increments soldCount. The second one is evaluated against the new value, fails the guard, and matches nothing. It cannot “also win”.

Multi-line carts

An order can hold up to 50 lines (for example three Standard and two VIP). Lines are claimed one at a time, each with its own atomic guard. If any line fails, every line already claimed for that order is rolled back, and the order fails as a whole. You never end up with a buyer who got their Standard tickets but not their VIP ones.

Optional Redis fast path for high-demand events

For on-sales that expect a large burst, Blend can put the counters in Redis ahead of MongoDB. Each ticket type has a key of the form inv:{eventId}:t:<ticketId> holding { cap, rem }, capacity and remaining. Every line in an order is decremented in one Lua script, which is all-or-nothing across the whole order: either every line had enough remaining and all of them are decremented, or nothing changes.

When inventory is claimed

This is the counterintuitive part, so it is stated plainly: for a paid order, the counters above are not touched when you reserve. They are touched when you confirm.

1. Reserve

   Blend validates the cart, prices it, and creates a pending order with an orderId and an amount. Nothing has been taken from the event's counts yet.

2. You charge the buyer on your rail

   Toters Pay, or whatever you use. Blend is not involved in this step.

3. Confirm

   Your backend calls POST /v1/channel/orders/confirm. This is when Blend runs the atomic claim. If it succeeds, the order becomes paid and the ticket is issued.

4. If the claim fails at that moment

   That is a genuine race: someone else's confirm took the last ticket between your reserve and your confirm. Blend cancels the registration and the payment must be refunded. Because you took the payment, the refund is yours to make; the confirm endpoint tells you so explicitly with 409 CONFIRM_FAILED and refundRequired: true.

Design for this. Keep the time between reserve and confirm short, and make sure the code path that handles a confirm failure can issue a refund without a human in the loop.

Powered by

Reserved seating: holds in Redis

Events with a seat map work differently. A specific seat cannot be “counted”; it is either free, held by someone who is deciding, or booked. While a buyer is choosing seats, Blend places a hold on them so nobody else can pick the same seat in the meantime.

Lifetimes

How a hold is taken

The hold is written by a single Lua script. Every requested seat must be free (or already held by your own token, re-holding your own seats is allowed) and must not be blocked by the organiser. If any seat fails that test, nothing is written at all. You either hold the whole selection or none of it, and no two buyers can hold the same seat.

Holds expire by Redis key TTL. There is no sweeper job that runs every minute and might lag behind; when the TTL is reached, the seat is free at that exact moment.

Seats become permanently booked only when the payment is confirmed, the same rule as general admission. A hold is a promise that nobody else will take the seat while the buyer decides, not a booking.

Seat endpoints inside a session

These run inside a buyer session (authenticated by the session cookie set when the session URL was opened). In the embedded checkout, Blend's own checkout page calls them; you do not need to call them yourself unless you are building a custom seat picker.

{
  "expiresInSeconds": 600
}

// Only the timing field is shown here.
// The hold actually lives 720 seconds. The extra 120 are hidden grace
// so a buyer who pays at the last visible second is not cut off.

Related errors

These are returned by checkout when inventory or a hold does not cooperate.

Next