Selling seats is harder than it looks. At 10 AM when Taylor Swift tickets go on sale, you have 50,000 seats and 500,000 concurrent buyers. You need to sell each seat exactly once. Overselling is a business disaster. Underselling (seats going unsold because they were locked but not purchased) is revenue loss. The core problem: how do you keep seat inventory consistent under massive concurrent load?

Why This Is Hard#

A seat has three states: available, held, sold. The transition from available to held must be atomic. If two buyers both check “is seat A12 available?” and both see “yes”, then both proceed to hold it, you’ve oversold. This is a classic race condition that gets worse at scale.

The naive fix — a database row lock — works at small scale. At Taylor Swift scale, row-level locks become a bottleneck: 500,000 concurrent transactions waiting on locks for the same rows.

Inventory Segmentation#

Split the venue into sections and shard by section. Seat A12 lives on one database shard. Seat B15 lives on another. Buyers are routed to the shard for their requested section. Contention is now localized to buyers who want the same section, not all buyers competing on a single lock.

Within a section, use optimistic concurrency with a version number. The seat row has a version column. To hold a seat: UPDATE seats SET status='held', holder=X, version=version+1 WHERE seat_id=A12 AND status='available' AND version=5. If the update affects 0 rows, someone else got it first. Retry with a different seat.

graph TD A[Buyer requests seat A12] --> B[Read seat: status=available, version=5] B --> C[UPDATE seats SET status=held WHERE seat_id=A12 AND version=5] C --> D{Rows affected?} D --> |1 row| E[Hold successful: seat reserved for buyer] D --> |0 rows| F[Concurrent modification: seat taken] F --> G[Return next available seat from section] style A fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style B fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style C fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style D fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style E fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style F fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff style G fill:#000000,stroke:#00ff00,stroke-width:2px,color:#fff

The Redis Layer#

Database writes for every seat check is expensive. Put available seat counts in Redis. Buyers first decrement a Redis counter for their section: DECR section:A:available. If the result goes negative, no seats available in that section, fail fast before touching the database. If positive, proceed to the database to claim a specific seat.

This pre-filters failed requests at the cache layer. Only buyers who successfully decremented the counter attempt a database write. Under flash sale load, this reduces database write traffic by 90%+.

At Oracle#

We had a similar problem with license seat allocation: enterprise customers purchased N seats, multiple concurrent users could activate licenses, and overselling wasn’t acceptable. We used a Redis counter for fast availability checks and a database row version for the actual allocation. The pattern was identical: decrement Redis first, then do a versioned UPDATE, roll back the Redis decrement on database failure. Under our worst concurrent activation bursts (50+ users activating within seconds), we had zero oversells across 18 months.

What I’m Learning#

Seat inventory consistency is a special case of the write-under-contention problem. The solution is always the same: reduce the surface area of contention (shard by section), use optimistic concurrency for the actual claim (versioned UPDATE), and pre-filter hopeless requests at a fast layer (Redis counter) before they reach the database.

Have you dealt with inventory consistency problems at scale, and what approach did you use?