Design a Mobile Event Ticketing App: Ticketmaster, AXS, DICE

“Design Ticketmaster” or “design an event ticketing app” is a senior+ mobile system design prompt that combines extreme load spikes (a popular tour can attract millions of buyers in minutes), real-time inventory, anti-bot defenses, and the unforgiving venue-entry UX. Ticketmaster, AXS, DICE, SeatGeek, and Eventbrite are the references. The interview tests how you handle bursty load and mobile-critical-path UX.

Clarify scope

  • Buyer side, organizer side, or both?
  • General admission, seated, or VIP packages?
  • Resale market in scope?
  • Mobile-only entry or paper tickets too?
  • International or single-country?

The on-sale spike

The defining workload challenge:

  • Taylor Swift Eras Tour on-sale: 14M+ users hit Ticketmaster simultaneously
  • Inventory of N seats; demand 100x N within minutes
  • Bot pressure tries to claim everything in milliseconds
  • UX: queue with position display, expected wait time, dropouts

The waiting room / queue

  • Pre-sale users see “You are in line. Position: 12,847”
  • Periodic position updates (every 30 sec)
  • Estimated wait time
  • When admitted: 10-minute exclusive window to complete checkout
  • If they leave the queue: lose place; have to re-enter

Server-side: a single queue per event with FIFO ordering; clients hold a token that gates access to the inventory API.

Inventory model

  • Seat-level state: available, held, sold
  • Hold has a TTL (typically 5–10 min)
  • Atomic compare-and-swap on hold transitions
  • Released holds return to inventory
  • Sharded by section for write throughput

The seat picker

  • SVG or Canvas rendering of the venue map
  • Color-coded by section / availability
  • Tap to select; shows price and view-from-seat photo
  • Hold seat for 5 min while user completes purchase
  • Real-time updates: another user grabs the seat → it disappears from your map (with a brief explanation)

Anti-bot defenses

  • CAPTCHA at queue entry
  • Device fingerprinting (Akamai, Cloudflare, custom)
  • Rate limiting per account, per IP, per device
  • Behavioral signals (mouse movement, dwell time)
  • Phone number verification before purchase
  • Continuous arms race; not “solved”

Mobile entry — the venue-night critical path

Cannot fail when you are in line at the gate:

  • Ticket cached locally; works without signal (venue Wi-Fi often saturated)
  • Rotating barcode (changes every 60 sec) to prevent screenshot fraud
  • Apple Wallet / Google Wallet integration
  • Brightness boost when ticket is shown
  • NFC-tap variant (Apple Wallet supports)
  • Pre-event reminder push to download tickets while on home Wi-Fi

The rotating barcode story

  • Server issues a ticket with a secret + sequence
  • Client generates HMAC-based time-rotating barcode every minute
  • Scanner at gate validates against server (online) or last-known-good (offline)
  • Defeats screenshot-and-resale of barcodes
  • Slight clock-skew tolerance built in

Transfers and resale

  • Transfer = give ticket to friend’s account; original ticket invalidated
  • Resale = list on the platform marketplace; gets resold; original invalidated
  • Verified resale features: face-value caps, auto-pricing, anti-scalping rules where required (e.g., NY law)

Push notifications

  • “Tickets go on sale tomorrow at 10 AM”
  • “Your queue position is approaching” — only if they are in queue and away from the app
  • “Doors open soon” reminder day-of
  • “Show now starting” if user is in venue

Live Activities (iOS) / Live Updates (Android)

  • Active queue position on lock screen
  • Day-of: time-to-doors, expected weather, parking link
  • Show running indicator if mid-event with set timing

Performance considerations

  • App must work on low-end Android phones (concert demographic spans devices)
  • Battery awareness: rotating barcode wakes the screen briefly; do not drain
  • Memory: ticket assets cached but not enormous
  • Network: graceful degradation when bandwidth is limited at venue

Compliance and consumer protection

  • Bot detection required by US BOTS Act and similar
  • Refund / cancellation policy clear in app
  • Per-state resale price-cap laws
  • EU consumer protection rights for events
  • Accessible seating disclosure

What separates senior from staff

Senior candidates draw the queue + inventory + entry pipeline. Staff candidates handle the rotating-barcode security model, the anti-bot defenses, and the offline-entry-must-work UX. Principal candidates address the multi-million-user spike with concrete capacity planning and the compliance landscape across jurisdictions.

Frequently Asked Questions

Why are these apps so often broken on huge on-sales?

The capacity is genuinely hard — peak load is 100–1000x average. Some failures are bot-driven; others are real demand exceeding capacity. The fix is largely operational (more capacity, better queue management) plus regulation.

How do I handle resale anti-scalping?

Verified resale platforms with face-value or modest-markup caps. Some artists (Pearl Jam, Robert Smith) impose stricter limits via the platform. Implementation is policy + UI; the technology is straightforward.

What about NFT tickets?

Tried by some platforms (DICE, Yellowheart) with mixed results. Provides clear ownership but the venue-entry UX is the same QR/NFC flow. Hype higher than adoption in 2026.

Scroll to Top