Design a Multi-Region Event Ticketing System

Read the full interview experience this question came from →

Quick Overview

Design a read-heavy event ticketing service with search, regional reads, ten-minute seat holds, payments, and authoritative inventory. The solution covers atomic state transitions, expiration, hot-event scaling, event-region routing, uncertain payments, failover fencing, and checkout under extreme network latency.

Design a Multi-Region Event Ticketing System

Company: Addepar

Role: Software Engineer

Category: System Design

Difficulty: medium

Interview Round: Technical Screen

# Design a Multi-Region Event Ticketing System Design an event ticketing system where users can view and search events and book seats. An event occurs at a venue with multiple sections, and sections may have different prices. During checkout, selected tickets are held for 10 minutes. A successful payment changes them to sold; an expired hold releases them. The system is read-heavy, serves users across the United States, and may later sell tickets for events in other countries. Start with core entities and the functional flow, then discuss scale and regional routing. Finally, consider an extreme scenario where round-trip network latency can be several minutes and may approach the checkout window. ### Clarifying Questions to Ask - Are seats individually assigned, general admission, or both? - May one order contain tickets from multiple events or regions? - Does the 10-minute hold begin when inventory is reserved or when the checkout page loads? - Which payment outcomes are synchronous, asynchronous, or uncertain? - What search freshness and booking availability guarantees are required? ### What a Strong Answer Covers - User, event, venue, section, seat or ticket, reservation, order, payment attempt, and price snapshot entities. - Browse and search read paths separated from an authoritative inventory write path. - Atomic `AVAILABLE -> HELD -> SOLD` transitions, hold expiration, idempotency, and uncertain payment reconciliation. - Caching, read replicas, search indexes, event-based partitioning, and hot-event protection. - Event-region ownership, global routing, cross-region failure behavior, and server-authoritative expiration. - Options and trade-offs when network latency consumes much of the checkout window. ### Follow-up Questions 1. How do you prevent two users from holding the same seat during a sudden on-sale spike? 2. What happens when the payment provider times out just before the reservation expires? 3. How can nearby regions serve event pages while only the event's home region mutates inventory? 4. How would you change the checkout protocol for users whose network round trip takes several minutes?

Overview: Design a read-heavy event ticketing service with search, regional reads, ten-minute seat holds, payments, and authoritative inventory. The solution covers atomic state transitions, expiration, hot-event scaling, event-region routing, uncertain payments, failover fencing, and checkout under extreme network latency.

Read the full Addepar Software Engineer interview experience this question came from

|Home/System Design/Addepar
A
Addepar
Aug 20, 2026
mediumSoftware EngineerTechnical ScreenSystem Design
0
0

Design a Multi-Region Event Ticketing System

Design an event ticketing system where users can view and search events and book seats. An event occurs at a venue with multiple sections, and sections may have different prices.

During checkout, selected tickets are held for 10 minutes. A successful payment changes them to sold; an expired hold releases them. The system is read-heavy, serves users across the United States, and may later sell tickets for events in other countries.

Start with core entities and the functional flow, then discuss scale and regional routing. Finally, consider an extreme scenario where round-trip network latency can be several minutes and may approach the checkout window.

Clarifying Questions to Ask Guidance

  • Are seats individually assigned, general admission, or both?
  • May one order contain tickets from multiple events or regions?
  • Does the 10-minute hold begin when inventory is reserved or when the checkout page loads?
  • Which payment outcomes are synchronous, asynchronous, or uncertain?
  • What search freshness and booking availability guarantees are required?

What a Strong Answer Covers Guidance

  • User, event, venue, section, seat or ticket, reservation, order, payment attempt, and price snapshot entities.
  • Browse and search read paths separated from an authoritative inventory write path.
  • Atomic AVAILABLE -> HELD -> SOLD transitions, hold expiration, idempotency, and uncertain payment reconciliation.
  • Caching, read replicas, search indexes, event-based partitioning, and hot-event protection.
  • Event-region ownership, global routing, cross-region failure behavior, and server-authoritative expiration.
  • Options and trade-offs when network latency consumes much of the checkout window.

Follow-up Questions Guidance

  1. How do you prevent two users from holding the same seat during a sudden on-sale spike?
  2. What happens when the payment provider times out just before the reservation expires?
  3. How can nearby regions serve event pages while only the event's home region mutates inventory?
  4. How would you change the checkout protocol for users whose network round trip takes several minutes?

Submit Your Answer to Earn 20XP

Sign in to leave a comment

Loading comments...