Design a Ticket Booking System (Ticketmaster / BookMyShow)

Given (Taylor Swift-scale event):
  Venue capacity: 70,000 seats
  Registered interest: 14M users (Ticketmaster reported this for Eras Tour)
  Users who attempt to buy at sale time: ~3.5M (25% conversion from interest)
  Sale window: seats sell out in 2-5 minutes

Peak concurrent users:
  3.5M users hitting the system within a 30-second window
  → ~3.5M concurrent connections at peak

Requests per second (peak):
  Each user refreshes seat map every 2-3 seconds while browsing
  3.5M users × 0.4 requests/sec = 1.4M requests/sec (seat availability reads)
  
  Reservation attempts:
  3.5M users competing for 70K seats = 50:1 contention ratio
  All 3.5M attempt to reserve within ~60 seconds
  → ~58K reservation attempts/sec (writes)

Normal day (non-spike):
  50M monthly active users
  Average 5M daily visits (browsing events)
  ~5K ticket purchases/sec across all events
  → 100× less than peak. The spike IS the design constraint.

Seat state transitions during peak sale:
  Hold attempts:     58K/sec (most will fail — seat already taken)
  Successful holds:  ~1.2K/sec (70K seats ÷ 60 seconds)
  Hold expirations:  ~200/sec (users who abandon checkout)
  Payment confirms:  ~1K/sec (successful purchases)
  Seat releases:     ~200/sec (payment failures + expirations)

Contention analysis (worst case — front row center):
  1 specific seat × 10,000 users wanting it = 10,000 concurrent CAS attempts
  Only 1 succeeds. 9,999 get "seat unavailable" and must retry elsewhere.
  → Hot seat problem: some seats have 10,000× more contention than others.

Implication:
  → Per-seat locking is mandatory (not per-event, not per-section)
  → Redis SETNX gives O(1) atomic reservation — no lock waiting
  → Failed attempts must be fast (<10ms) so users can try another seat
  → "Best available" algorithm must avoid hot-seat contention entirely

Event metadata:
  ~500K active events at any time (globally)
  Average event: 2KB (title, description, dates, venue_id, pricing tiers)
  Total: 500K × 2KB = 1 GB (trivial — fits in cache)

Venue and seat maps:
  ~50K venues globally
  Average venue: 30K seats with section/row/seat coordinates
  Seat record: 100 bytes (venue_id, section, row, seat_num, coordinates, tier)
  Total: 50K venues × 30K seats × 100 bytes = 150 GB
  → Fits in a single Postgres instance. Rarely changes (venue layout is static).

Booking records:
  ~200M tickets sold/year (Ticketmaster does ~500M globally)
  Per booking: 500 bytes (booking_id, user_id, event_id, seats[], payment_ref, timestamps)
  Annual: 200M × 500 bytes = 100 GB/year
  → Modest. Standard Postgres with partitioning by event_date.

Seat availability (hot state):
  Per event during sale: 70K seats × 50 bytes (seat_id, state, holder, expiry)
  = 3.5 MB per event in Redis
  → Even 1000 concurrent sales = 3.5 GB in Redis. Trivial.

Implication:
  → This is NOT a storage-heavy system. It's a concurrency-heavy system.
  → The entire hot inventory for a sale fits in Redis memory.
  → Postgres is the source of truth; Redis is the real-time coordination layer.

Seat map polling (peak):
  3.5M users × seat map response (5KB compressed) every 3 seconds
  = 3.5M × 5KB / 3s = 5.8 GB/s outbound
  → This MUST go through CDN with short TTL (1-2 seconds)
  → Origin only serves cache misses

WebSocket connections (real-time seat updates):
  If using WebSocket for live seat map:
  3.5M concurrent connections × 20KB state each = 70 GB memory
  → 7,000 WebSocket servers at 500K connections each? Too expensive.
  → Better: short-polling with 2-second CDN TTL for seat map
  → WebSocket only for the user's own booking status (much fewer connections)

API gateway load:
  1.4M read requests/sec + 58K write requests/sec = ~1.5M req/sec
  → 150 API servers at 10K req/sec each
  → Auto-scale from 20 servers (normal) to 150 (peak) in <60 seconds

Implication:
  → CDN absorbs 95%+ of read traffic (seat map is same for all users)
  → Only reservation writes hit origin servers
  → WebSocket is overkill for seat map — short-poll with CDN is cheaper and simpler

Request:
  POST /api/v1/reservations
  Headers:
    Authorization: Bearer <jwt>
    Idempotency-Key: "uuid-v4-client-generated"
    X-Queue-Token: "waiting-room-token"  // proves user passed the queue
  Body:
    {
      "event_id": "evt_taylor_swift_2026",
      "seats": [
        { "section": "A", "row": "12", "seat": "7" },
        { "section": "A", "row": "12", "seat": "8" }
      ],
      "hold_duration_seconds": 600  // server may override to enforce max
    }

Response (201 Created):
    {
      "reservation_id": "res_8f3a2b1c",
      "status": "held",
      "seats": [...],
      "expires_at": "2026-03-15T10:10:00Z",  // 10 min from now
      "payment_deadline": "2026-03-15T10:10:00Z",
      "links": {
        "payment": "/api/v1/reservations/res_8f3a2b1c/payment",
        "cancel": "/api/v1/reservations/res_8f3a2b1c"
      }
    }

Response (409 Conflict — seat already held):
    {
      "error": "SEAT_UNAVAILABLE",
      "message": "One or more seats are no longer available",
      "unavailable_seats": [{ "section": "A", "row": "12", "seat": "7" }],
      "suggestion": "Try /api/v1/events/evt_.../best-available?count=2"
    }

Request:
  POST /api/v1/reservations/res_8f3a2b1c/payment
  Headers:
    Authorization: Bearer <jwt>
    Idempotency-Key: "uuid-v4-payment-attempt"
  Body:
    {
      "payment_method": "card",
      "payment_token": "tok_visa_4242",  // tokenized by client-side SDK
      "amount_cents": 15000,
      "currency": "USD"
    }

Response (202 Accepted — payment processing):
    {
      "payment_id": "pay_9d4e3f2a",
      "status": "processing",
      "reservation_id": "res_8f3a2b1c",
      "poll_url": "/api/v1/payments/pay_9d4e3f2a/status"
    }

Response (410 Gone — hold expired):
    {
      "error": "HOLD_EXPIRED",
      "message": "Your seat hold expired. Seats have been released.",
      "expired_at": "2026-03-15T10:10:00Z"
    }

Request:
  GET /api/v1/events/evt_taylor_swift_2026/seats?section=A
  Headers:
    Cache-Control: max-age=2  // client accepts 2-second stale data

Response (200 OK):
    {
      "event_id": "evt_taylor_swift_2026",
      "section": "A",
      "updated_at": "2026-03-15T10:00:03Z",
      "seats": [
        { "row": "1", "seat": "1", "status": "sold", "tier": "vip" },
        { "row": "1", "seat": "2", "status": "held", "tier": "vip" },
        { "row": "1", "seat": "3", "status": "available", "tier": "vip", "price_cents": 25000 },
        ...
      ],
      "summary": {
        "total": 500,
        "available": 312,
        "held": 45,
        "sold": 143
      }
    }

Cache strategy:
  → CDN caches this response for 2 seconds (short TTL)
  → 3.5M users polling every 3s = only ~1 origin hit per 2 seconds per section
  → Seat map is "eventually consistent" for reads (acceptable)
  → Reservation writes are strongly consistent (non-negotiable)

Request:
  POST /api/v1/events/evt_taylor_swift_2026/best-available
  Headers:
    Authorization: Bearer <jwt>
    Idempotency-Key: "uuid-v4"
    X-Queue-Token: "waiting-room-token"
  Body:
    {
      "count": 4,
      "preferences": {
        "contiguous": true,        // seats must be adjacent
        "tier": "premium",         // price tier preference
        "max_price_cents": 20000   // per-seat budget
      }
    }

Response (201 Created):
    {
      "reservation_id": "res_7c2d1e4f",
      "status": "held",
      "seats": [
        { "section": "B", "row": "5", "seat": "10", "price_cents": 18000 },
        { "section": "B", "row": "5", "seat": "11", "price_cents": 18000 },
        { "section": "B", "row": "5", "seat": "12", "price_cents": 18000 },
        { "section": "B", "row": "5", "seat": "13", "price_cents": 18000 }
      ],
      "expires_at": "2026-03-15T10:10:00Z"
    }

Response (404 — no matching seats available):
    {
      "error": "NO_MATCHING_SEATS",
      "message": "No 4 contiguous premium seats available under $200",
      "alternatives": [
        { "tier": "premium", "count": 2, "price_cents": 18000 },
        { "tier": "standard", "count": 4, "price_cents": 12000 }
      ]
    }

1. User enters waiting room:
   GET /api/v1/events/evt_.../queue/join
   → Returns: { "position": 45231, "estimated_wait": "4m 30s", "token": null }

2. User polls for position updates:
   GET /api/v1/events/evt_.../queue/status?session=<session_id>
   → Returns: { "position": 12003, "estimated_wait": "1m 15s", "token": null }

3. User reaches front of queue:
   GET /api/v1/events/evt_.../queue/status?session=<session_id>
   → Returns: { "position": 0, "token": "qt_signed_jwt_...", "expires_in": 300 }

4. User uses token to access booking APIs:
   POST /api/v1/reservations
   Headers: X-Queue-Token: "qt_signed_jwt_..."
   → Server validates: signature, expiry, event_id match, single-use

Token properties:
  - Signed JWT (HMAC-SHA256) — can't be forged
  - Contains: user_id, event_id, issued_at, expires_at
  - Single-use: marked as consumed after first successful reservation
  - Expires in 5 minutes if unused (user took too long after leaving queue)

-- Venues are static — created once, rarely updated
CREATE TABLE venues (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  city TEXT NOT NULL,
  country TEXT NOT NULL,
  total_capacity INT NOT NULL,
  seat_map_version INT DEFAULT 1,  -- bumped when layout changes
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB
);

-- Sections within a venue (e.g., "Floor", "Balcony Left", "VIP Box")
CREATE TABLE venue_sections (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  venue_id UUID REFERENCES venues(id),
  name TEXT NOT NULL,           -- "Section A", "Floor", "Balcony"
  tier TEXT NOT NULL,           -- "vip", "premium", "standard", "economy"
  row_count INT NOT NULL,
  seats_per_row INT NOT NULL,
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB
);

-- Individual seats — pre-generated from venue layout
CREATE TABLE seats (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  venue_id UUID REFERENCES venues(id),
  section_id UUID REFERENCES venue_sections(id),
  row_label TEXT NOT NULL,      -- "A", "B", "1", "2"
  seat_number INT NOT NULL,
  x_coord FLOAT,               -- for seat map rendering
  y_coord FLOAT,
  is_accessible BOOLEAN DEFAULT false,  -- wheelchair accessible
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB,
  UNIQUE(venue_id, section_id, row_label, seat_number)
);

-- Events — the thing users buy tickets for
CREATE TABLE events (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  venue_id UUID REFERENCES venues(id),
  title TEXT NOT NULL,
  artist TEXT,
  category TEXT NOT NULL,       -- "concert", "sports", "theater"
  event_date TIMESTAMPTZ NOT NULL,
  sale_start TIMESTAMPTZ NOT NULL,  -- when tickets go on sale
  sale_end TIMESTAMPTZ,
  status TEXT NOT NULL DEFAULT 'upcoming',  -- upcoming, on_sale, sold_out, completed, cancelled
  max_tickets_per_user INT DEFAULT 6,
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB
);

-- Pricing per section per event (same venue, different prices per event)
CREATE TABLE event_pricing (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  event_id UUID REFERENCES events(id),
  section_id UUID REFERENCES venue_sections(id),
  price_cents INT NOT NULL,
  currency TEXT NOT NULL DEFAULT 'USD',
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB,
  UNIQUE(event_id, section_id)
);

-- Bookings — the confirmed purchase record (append-only)
CREATE TABLE bookings (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  user_id UUID NOT NULL,
  event_id UUID REFERENCES events(id),
  status TEXT NOT NULL DEFAULT 'confirmed',  -- confirmed, cancelled, refunded
  total_amount_cents INT NOT NULL,
  currency TEXT NOT NULL,
  payment_id TEXT,              -- external payment reference
  booked_at TIMESTAMPTZ NOT NULL,
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB
);

-- Booked seats — links bookings to specific seats
CREATE TABLE booking_seats (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  booking_id UUID REFERENCES bookings(id),
  event_id UUID REFERENCES events(id),
  seat_id UUID REFERENCES seats(id),
  price_cents INT NOT NULL,
  created_at TIMESTAMPTZ,
  updated_at TIMESTAMPTZ,
  delete_info JSONB,
  UNIQUE(event_id, seat_id)  -- a seat can only be booked once per event
);

# Seat state — one key per seat per event
# Key pattern: seat:{event_id}:{seat_id}
# Value: JSON with state, holder, and expiry

SET seat:evt_123:seat_A12_7 '{
  "state": "held",
  "holder_id": "user_abc",
  "reservation_id": "res_8f3a2b1c",
  "held_at": 1710496200,
  "expires_at": 1710496800
}' EX 600  // TTL = 10 minutes (auto-release on expiry)

# When seat is available: key does NOT exist in Redis
# When seat is held: key exists with TTL
# When seat is sold: key exists with NO TTL (permanent until event ends)

# ─────────────────────────────────────────────────────────────

# Event-level availability summary (for fast seat map responses)
# Updated atomically on every state transition

HSET event:evt_123:availability section_A_available 312
HSET event:evt_123:availability section_A_held 45
HSET event:evt_123:availability section_A_sold 143

# ─────────────────────────────────────────────────────────────

# User's active holds (to enforce max-tickets-per-user)
# Key pattern: user_holds:{event_id}:{user_id}

SADD user_holds:evt_123:user_abc "seat_A12_7" "seat_A12_8"
EXPIRE user_holds:evt_123:user_abc 600  // same TTL as seat hold

# ─────────────────────────────────────────────────────────────

# Idempotency store (prevent double-reservations from retries)
# Key pattern: idempotency:{idempotency_key}

SET idempotency:uuid-v4-abc '{"reservation_id":"res_8f3a2b1c","status":"held"}'
EXPIRE idempotency:uuid-v4-abc 3600  // keep for 1 hour

Static layout (cached forever, invalidated only on venue renovation):
  Source: Postgres → CDN (immutable until seat_map_version changes)
  Contains: section boundaries, row positions, seat coordinates, tier colors
  Size: ~200KB per venue (compressed SVG paths + seat coordinates)

Dynamic availability (refreshed every 2 seconds):
  Source: Redis → API → CDN (2-second TTL)
  Contains: per-seat status (available/held/sold)
  Size: ~5KB per section (just status enum per seat)

Client composition:
  1. Load static layout once (from CDN, cached in browser)
  2. Poll dynamic availability every 2-3 seconds (from CDN)
  3. Overlay availability on layout → render colored seat map
  
  → Static + dynamic separation means 99% of bandwidth is the tiny
    availability payload, not the full seat map geometry.

Events published to Kafka after booking confirmation:

1. booking.confirmed
   → Notification Service: send confirmation email + e-ticket PDF
   → Analytics Service: update sales dashboard, revenue tracking
   → Inventory Service: write-behind to Postgres (permanent record)

2. seat.hold_expired
   → Inventory Service: release seat in Redis (TTL handles this automatically)
   → Notification Service: "Your hold expired" push notification
   → Waitlist Service: notify next user in waitlist (if applicable)

3. payment.failed
   → Reservation Service: release held seats immediately (don't wait for TTL)
   → Notification Service: "Payment failed, seats released" email

4. event.sold_out
   → Event Service: update event status, stop accepting queue entries
   → Notification Service: notify waitlisted users
   → CDN: purge cached seat map (force refresh to show sold-out state)

┌───────────┐     reserve()      ┌────────┐     payment_confirmed()    ┌────────┐
│ AVAILABLE │ ──────────────────→ │  HELD  │ ─────────────────────────→ │  SOLD  │
└───────────┘                     └────────┘                            └────────┘
      ↑                                │                                     
      │         hold_expired()         │                                     
      │         user_cancelled()       │                                     
      └────────────────────────────────┘                                     
                                                                             
      ↑                                                                      
      │         refund_processed()                                           
      │         (creates new availability — not a state reversal)            
      └──────────────────────────────────────────────────────────────────────┘

Invalid transitions (must be rejected):
  AVAILABLE → SOLD    (can't skip the hold — payment takes time)
  HELD → HELD         (can't re-hold an already-held seat)
  SOLD → AVAILABLE    (refunds are a separate business event)
  SOLD → HELD         (impossible — sold is terminal)

-- KEYS[1] = "event:{eventId}:seats"
-- ARGV = [seat_id_1, seat_id_2, ..., seat_id_N, user_id, expiry, res_id]

local seat_count = #ARGV - 3  -- last 3 args are user_id, expiry, res_id
local user_id = ARGV[seat_count + 1]
local expiry = ARGV[seat_count + 2]
local res_id = ARGV[seat_count + 3]

-- Phase 1: Check ALL seats are available (read phase)
for i = 1, seat_count do
  local status = redis.call('HGET', KEYS[1], ARGV[i])
  if status ~= 'available' then
    return {0, ARGV[i], status}  -- REJECTED: which seat failed and why
  end
end

-- Phase 2: Claim ALL seats atomically (write phase)
-- If we reach here, all seats were available at check time.
-- Since Lua scripts are atomic, no other script can interleave.
for i = 1, seat_count do
  local hold_value = 'held:' .. user_id .. ':' .. expiry
  redis.call('HSET', KEYS[1], ARGV[i], hold_value)
end

return {1, seat_count}  -- SUCCESS: all seats held

T+0:00  User clicks "Reserve" → Lua script claims seat → hold starts
T+0:01  Client receives confirmation, shows 9:59 countdown
T+0:30  User enters payment details
T+2:00  User clicks "Pay" → payment processing begins
T+2:05  Payment gateway responds "success"
T+2:06  Hold converts to "sold" → seat permanently allocated

─── OR ───

T+0:00  Hold starts (10:00 remaining)
T+5:00  User abandons page (no payment attempt)
T+10:00 Hold expires → expiration worker releases seat
T+10:01 Seat appears as "available" to other users

─── OR (the dangerous edge case) ───

T+0:00   Hold starts
T+9:50   User clicks "Pay" (10 seconds before expiry)
T+9:55   Payment gateway processing...
T+10:00  Hold timer fires! But payment is in-flight...
T+10:03  Payment gateway returns "success"
         → Race condition: is the seat sold or released?

// Payment confirmation handler
async function confirmPayment(reservationId: string, paymentResult: PaymentResult) {
  // Use a Lua script that atomically checks seat state before confirming
  const result = await redis.eval(CONFIRM_PAYMENT_SCRIPT, {
    keys: [`event:${eventId}:seats`],
    args: [seatId, reservationId, 'sold']
  });
  
  // The Lua script:
  // 1. Check if seat is still "held" by THIS reservation
  // 2. If yes → set to "sold" (payment wins)
  // 3. If seat was already released (expiration won) → payment fails
  //    → trigger refund for the charge that already went through
  
  if (result === 'already_released') {
    // Expiration worker beat us. Seat was given to someone else.
    // We must refund the payment that just succeeded.
    await refundPayment(paymentResult.chargeId);
    return { status: 'expired', message: 'Hold expired during payment' };
  }
  
  return { status: 'confirmed', bookingId: result };
}

// Key insight: the Lua script is the single arbiter.
// Both the expiration worker and the payment handler go through it.
// Whoever's Lua script executes first wins. The other gets a clean rejection.

// Best-available is a two-phase operation:
// Phase 1: Find candidates (read — can be slightly stale)
// Phase 2: Claim atomically (write — must be strongly consistent)

async function bestAvailable(eventId: string, count: number, preferences: Preferences) {
  const redis = getRedisForEvent(eventId);
  
  // Phase 1: Get all available seats in preferred sections
  // This is a HSCAN or pre-computed sorted list
  const available = await redis.eval(GET_AVAILABLE_SCRIPT, {
    keys: [`event:${eventId}:seats`],
    args: [preferences.section, preferences.priceTier]
  });
  
  // Score and rank candidates (adjacency, row proximity, aisle preference)
  const ranked = scoreCandidates(available, count, preferences);
  
  // Phase 2: Attempt to claim top-ranked candidates atomically
  // If any are taken between Phase 1 and Phase 2, try next candidates
  for (const candidateGroup of ranked) {
    const result = await redis.eval(CLAIM_MULTIPLE_SEATS_SCRIPT, {
      keys: [`event:${eventId}:seats`],
      args: [...candidateGroup.seatIds, userId, expiry, reservationId]
    });
    
    if (result[0] === 1) return { success: true, seats: candidateGroup };
    // If failed, try next candidate group (Lua script is still atomic)
  }
  
  return { success: false, reason: 'no_adjacent_seats_available' };
}

ENTRY PHASE (sale starts):
  1. User navigates to event page → CDN serves cached event info (normal)
  2. User clicks "Buy Tickets" → request hits waiting room edge worker
  3. Edge worker checks: does user have a valid queue token?
     - YES → proxy request to booking service (user already waited)
     - NO → assign queue position, return waiting room page

WAITING PHASE:
  4. User sees: "You are #45,231 in line. Estimated wait: 4 min 30 sec"
  5. Client polls every 5 seconds: GET /queue/status?session=<id>
  6. Edge worker responds with updated position (positions advance as
     users ahead complete or abandon)

RELEASE PHASE:
  7. User reaches front of queue
  8. Edge worker generates signed JWT token:
     { user_id, event_id, issued_at, expires_in: 300, nonce }
  9. Client receives token → redirected to seat selection page
  10. All subsequent booking API calls include X-Queue-Token header

BOOKING PHASE:
  11. Reservation Service validates token: signature, expiry, event match
  12. Token is marked as "consumed" after first successful reservation
  13. If user doesn't complete booking within 5 minutes, token expires
      → user must re-enter queue (but gets priority re-entry)

Static calculation:
  Booking service capacity: 50K reservations/sec
  Average user session: 45 seconds (select seats + checkout)
  Concurrent booking sessions: 50K × 45s = 2.25M users in booking flow
  
  But we don't want 2.25M concurrent — that's the max before degradation.
  Target: 70% utilization = ~1.5M concurrent booking sessions
  
  Release rate = (target_concurrent × completion_rate) / avg_session_time
  Release rate = (1.5M × 0.6) / 45s = 20K users/sec released from queue

Adaptive adjustment (feedback loop):
  Every 10 seconds, the waiting room checks:
  - Current booking service latency (p99)
  - Current Redis operation latency
  - Current payment gateway success rate
  
  If p99 latency > 400ms → reduce release rate by 20%
  If p99 latency < 200ms → increase release rate by 10%
  If payment gateway errors > 5% → pause releases for 30 seconds
  
  This feedback loop prevents the waiting room from overwhelming
  backends even if capacity changes mid-sale (server failure, etc.)

Example timeline (Taylor Swift sale):
  T+0s:    3.5M users arrive. All shuffled into queue.
  T+0-30s: Randomization window. No releases yet.
  T+30s:   Begin releasing at 20K users/sec
  T+60s:   600K users have entered booking flow
  T+120s:  Feedback loop detects p99 at 350ms → reduces to 16K/sec
  T+180s:  First users completing purchases. Seats selling fast.
  T+300s:  Event sold out. Queue closed. Remaining users notified.

Queue state storage:
  Option A: Redis cluster (centralized, strongly consistent positions)
  Option B: Durable Objects (Cloudflare) — per-event state at edge
  Option C: DynamoDB with DAX cache — serverless, auto-scaling

  Production choice: Redis cluster for position tracking +
  edge KV store for queue configuration (release rate, status)

Polling optimization:
  3.5M users polling every 5 seconds = 700K requests/sec to queue service
  
  Optimization 1: Long-polling (hold connection for up to 30s, respond
  immediately when position changes significantly)
  → Reduces polling to ~120K req/sec (6× reduction)
  
  Optimization 2: Batch position updates
  → Don't update position on every single departure
  → Update in batches of 100 (position changes from 45231 to 45131)
  → Users don't need per-person granularity
  
  Optimization 3: Estimated wait time is computed client-side
  → Server sends: { position, release_rate, avg_session_time }
  → Client computes: position / release_rate = estimated_wait
  → No server-side computation per poll

Token security:
  - HMAC-SHA256 signed with per-event rotating secret
  - Contains: user_id, event_id, issued_at, nonce
  - Single-use: nonce is stored in Redis SET, checked on first use
  - Expires in 5 minutes if unused
  - Cannot be transferred (bound to user_id from auth session)

HAPPY PATH (all steps succeed):

Step 1: HOLD SEATS (Inventory Service)
  Action:    Redis SETNX — atomically hold requested seats
  Success:   Seats marked as HELD with 10-min TTL
  Duration:  <5ms
  
Step 2: CREATE PAYMENT ORDER (Payment Service)
  Action:    Create payment record in DB, call payment gateway
  Success:   Payment intent created, gateway returns "processing"
  Duration:  200-500ms (external API call)

Step 3: AWAIT PAYMENT CONFIRMATION (async)
  Action:    Wait for payment gateway webhook (success/failure)
  Success:   Webhook confirms charge captured
  Duration:  1-30 seconds (depends on gateway, 3D Secure, etc.)

Step 4: CONFIRM BOOKING (Reservation Service)
  Action:    Transition seats HELD → SOLD (remove TTL)
             Write booking record to Postgres
  Success:   Seats permanently sold, booking confirmed
  Duration:  <50ms

Step 5: SEND CONFIRMATION (Notification Service)
  Action:    Email confirmation + e-ticket PDF, push notification
  Success:   User notified (async, non-blocking)
  Duration:  Async (doesn't block the saga)

─────────────────────────────────────────────────────────────────

COMPENSATION (rollback on failure):

If Step 2 fails (payment gateway error):
  Compensate Step 1: Release seat holds (DELETE Redis keys)
  → Seats immediately available for other users

If Step 3 fails (payment declined):
  Compensate Step 1: Release seat holds
  Compensate Step 2: Cancel payment intent (if created)
  → User sees "Payment declined. Seats released."

If Step 4 fails (Postgres write fails):
  Compensate Step 3: Refund the charge (payment was captured)
  Compensate Step 1: Release seat holds
  → User gets refund, seats released. Retry from scratch.

If Step 5 fails (notification service down):
  NO COMPENSATION. Booking is confirmed. Retry notification later.
  → Notification failure never rolls back a successful booking.

Payment outcomes and saga responses:

1. INSTANT SUCCESS (gateway returns "captured" synchronously)
   → Proceed to Step 4 (confirm booking) immediately
   → Rare with modern gateways (most are async)

2. PROCESSING (gateway returns "pending", will send webhook)
   → Wait for webhook. Set internal timeout = hold_expiry - 30 seconds.
   → If webhook arrives with "captured" → confirm booking
   → If webhook arrives with "failed" → release seats, notify user

3. TIMEOUT (no response from gateway within 10 seconds)
   → DO NOT assume failure. The charge might have succeeded.
   → Query gateway: GET /payments/{id}/status (idempotent read)
   → If "captured" → confirm booking
   → If "failed" → release seats
   → If "pending" → wait for webhook (extend hold if needed)
   → If gateway is unreachable → extend hold, retry query in 30 seconds

4. GATEWAY ERROR (5xx response)
   → Retry with exponential backoff (max 3 attempts)
   → If all retries fail → release seats, show "payment service unavailable"
   → DO NOT charge the user. Idempotency key prevents double-charge on retry.

5. WEBHOOK ARRIVES AFTER HOLD EXPIRED
   → Check if seats are still held by this user (Lua script)
   → If yes (hold was extended) → confirm booking
   → If no (hold expired, seats re-held by someone else) → REFUND
   → This is the critical race condition. Refund is the safe default.

Idempotency guarantee:
  Every payment attempt carries a unique idempotency key.
  If the same key is sent twice (retry after timeout):
  → Gateway returns the result of the first attempt
  → No double-charge, ever
  → Key format: "pay_{reservation_id}_{attempt_number}"