System Design: Ticketing System

By Michael Samuel Naeem · November 21, 2025 · 8 min read

System DesignBackendArchitectureDistributed Systems

Ticketmaster opens sales for a stadium show. Two hundred thousand people hit refresh at 10:00:00 AM for eight thousand seats. The system must never sell seat 14-A twice, must expire abandoned carts before hoarders lock inventory, and must stay up when payment webhooks lag thirty seconds. Ticketing is inventory management under adversarial load with a clock.

Core entities

Event ──< Section ──< Row ──< Seat
  │
  └── PricingTier (GA, VIP, early bird)

Hold (seat_id, user_id, expires_at, status)
Order (hold_ids[], payment_id, status)
Ticket (order_id, seat_id, barcode, status)

General admission simplifies to pool counters instead of per-seat maps: GA_pool_remaining = 500.

The hold lifecycle

Available → Held (TTL) → Sold
                ↓
            Expired → Available

-- Pessimistic: lock seat row
BEGIN;
SELECT * FROM seats WHERE id = $1 AND status = 'available' FOR UPDATE;
UPDATE seats SET status = 'held', hold_expires_at = now() + interval '10 minutes'
  WHERE id = $1;
COMMIT;

Optimistic alternative for GA pools:

UPDATE ga_inventory
SET remaining = remaining - 1
WHERE event_id = $1 AND remaining > 0
RETURNING remaining;

Zero rows updated = sold out. Atomic decrement is the entire trick for counter-based inventory.

Redis-backed holds for speed

Hot events push holds to Redis first, async sync to Postgres:

SET hold:evt-99:seat-14A user-42 EX 600 NX

NX fails if already held — instant conflict signal. Background worker persists holds to DB and reconciles. On payment success, promote to sold; on expiry, key vanishes and worker releases seat.

Trade-off: Redis/DB drift requires reconciliation jobs. Most high-scale ticket vendors accept eventual consistency with tight reconciliation.

Seat map vs best-available

Interactive seat map — user picks exact seat. Requires per-seat state, vector map tiles CDN-cached, WebSocket or poll for seat status updates as others hold.

Best available — algorithm picks contiguous block. Faster checkout, fewer round trips, easier to shard inventory by section.

Many systems offer both; flash sales often default to best-available to reduce contention on individual seat rows.

Payment integration

Never confirm ticket before payment clears:

1. Create hold
2. Redirect to payment / tokenize card
3. Payment webhook → confirm order → mark seats sold → emit tickets
4. Webhook failure / timeout → release hold

Idempotent webhook handling — Stripe may deliver twice. order_id uniqueness constraint and status state machine:

pending_payment → paid → fulfilled
               → failed → hold_released

Virtual waiting room

When demand exceeds capacity by 10x, uncontrolled access creates thundering herd on inventory service. Queue layer (Queue-it, Cloudflare Waiting Room, custom):

User lands on event page → enters queue token
Queue admits N users/minute to purchase flow
Purchase flow receives signed token validating queue admission

Protects backend; does not guarantee tickets — sets expectations.

Anti-abuse

Per-account purchase limits
CAPTCHA at queue entry
Device fingerprinting for bot detection
Resale market integration (optional) with transfer locks

Failure modes

Failure	Mitigation
Double sell	Atomic decrement, DB unique constraint on (event, seat)
Ghost holds	TTL + sweeper job
Payment success, DB fail	Outbox + reconciliation; manual support playbook
Hot row contention	Shard GA pools; section-level locks

Scale sketch

50k concurrent users in queue
5k holds/second peak
Hold TTL 10 minutes → ~3M active hold records worst case (most expire fast)
Postgres for source of truth; Redis for hot path

Reporting and reconciliation

Nightly jobs compare sold seat count to venue capacity and flag discrepancies. Finance teams need immutable audit logs of price paid per seat — append-only order events, not mutable row overwrites. Support tooling to transfer tickets between accounts must re-validate availability and emit new barcode while invalidating old.

Seat hold pattern

BEGIN;
SELECT * FROM seats WHERE id = $1 FOR UPDATE;
-- check available, insert hold with expiry
INSERT INTO holds (seat_id, user_id, expires_at) VALUES ($1, $2, NOW() + interval '10 minutes');
COMMIT;

Hold expires via cron — release seat if payment not completed. Never hold without TTL — ghost availability kills conversion.

Metrics worth dashboarding

For ticketing booking, alert on symptoms users feel—not only infrastructure CPU:

Signal	Why it matters
p95/p99 latency	Tail latency drives timeouts and retries upstream
Error rate by operation	Separates transient blips from systemic failure
Saturation (pool, queue, disk)	Shows how close you are to hard limits
Business counter (success/failure)	Ties technical metrics to revenue or task completion

Slice by version, region, and tenant during rollout. A flat global graph hides a bad canary.

Seat locking and double-booking prevention

Concert and airline booking share the same core problem: hold inventory during checkout with TTL. Optimistic locking on seat rows (UPDATE seats SET status='held' WHERE id=? AND status='available') fails closed when zero rows updated. Display held seats as unavailable to other users immediately via WebSocket or short-poll on seat map. When hold expires, broadcast seat release so waiting users can grab released inventory — this creates burst traffic; rate-limit seat map refreshes per client.

Payment timeout versus inventory hold

Hold TTL must exceed p99 payment completion time plus retry buffer — if Stripe checkout takes ninety seconds on mobile, a sixty-second hold guarantees double-booking complaints. Extend hold on payment-in-progress webhook, release on explicit cancel or timeout. Show countdown timer in UI synced to server hold expiry, not client clock.