Revision of System Design Interview: Designing a Ticket Booking System (Ticketmaster-style)

1

+

# System Design Interview: Designing a Ticket Booking System (Ticketmaster-style)

2

+

3

+

The hard part isn't browsing events; it's selling a limited number of seats to a crowd that all clicks "buy" in the same second.

4

+

5

+

## Requirements

6

+

7

+

- Browse events and see a seat map with availability.

8

+

- Hold seats for a few minutes during checkout; never sell the same seat twice.

9

+

- Survive "on-sale" spikes: 1M users arriving for 50k seats.

10

+

11

+

## Data model

12

+

13

+

- `event(id, venue_id, start_time)`

14

+

- `seat(event_id, seat_id, status, hold_expires_at, order_id)` with status in AVAILABLE / HELD / SOLD.

15

+

16

+

## Holding seats without double-selling

17

+

18

+

Use a conditional update so only one request can win a seat:

19

+

20

+

```sql

21

+

UPDATE seat

22

+

SET status = 'HELD', hold_expires_at = now() + interval '8 minutes', order_id = :order

23

+

WHERE event_id = :e AND seat_id = ANY(:seats)

24

+

AND (status = 'AVAILABLE' OR (status = 'HELD' AND hold_expires_at < now()));

25

+

```

26

+

27

+

If the number of updated rows is less than requested, roll back and tell the user those seats are gone. Expired holds are reclaimed by the same predicate, so no cleanup job is strictly required (one still helps keep the seat map accurate).

28

+

29

+

A Redis `SET seat:{e}:{s} order NX PX 480000` is a faster alternative for holds, but the database stays the source of truth for SOLD.

30

+

31

+

## Payment

32

+

33

+

Checkout calls the payment provider with an idempotency key. On success, flip HELD to SOLD in a transaction that checks the hold still belongs to this order. If the hold expired mid-payment, refund automatically.

34

+

35

+

## Handling the spike

36

+

37

+

- **Virtual waiting room**: put arriving users in a queue and admit them at a rate the booking service can handle. This is the single most important idea.

38

+

- Serve the seat map from a cache refreshed every second or two; it only needs to be approximately right because the hold step is authoritative.

39

+

- Rate-limit per user and use bot detection.

40

+

41

+

## Follow-ups

42

+

43

+

- General admission (no seat numbers): decrement a counter atomically instead of locking seats.

44

+

- Fairness: randomize queue position for people who arrived before the sale opened.

45

+

46

+

---

47

+

*Disclosure: I'm part of [Linkjob AI](https://www.linkjob.ai/), an AI interview assistant.*

linkjobai / System Design Interview: Designing a Ticket Booking System (Ticketmaster-style)

linkjobai revised this gist 18 hours ago · c65b6a2

		@@ -0,0 +1,47 @@
1	+	# System Design Interview: Designing a Ticket Booking System (Ticketmaster-style)
2	+
3	+	The hard part isn't browsing events; it's selling a limited number of seats to a crowd that all clicks "buy" in the same second.
4	+
5	+	## Requirements
6	+
7	+	- Browse events and see a seat map with availability.
8	+	- Hold seats for a few minutes during checkout; never sell the same seat twice.
9	+	- Survive "on-sale" spikes: 1M users arriving for 50k seats.
10	+
11	+	## Data model
12	+
13	+	- `event(id, venue_id, start_time)`
14	+	- `seat(event_id, seat_id, status, hold_expires_at, order_id)` with status in AVAILABLE / HELD / SOLD.
15	+
16	+	## Holding seats without double-selling
17	+
18	+	Use a conditional update so only one request can win a seat:
19	+
20	+	```sql
21	+	UPDATE seat
22	+	SET status = 'HELD', hold_expires_at = now() + interval '8 minutes', order_id = :order
23	+	WHERE event_id = :e AND seat_id = ANY(:seats)
24	+	AND (status = 'AVAILABLE' OR (status = 'HELD' AND hold_expires_at < now()));
25	+	```
26	+
27	+	If the number of updated rows is less than requested, roll back and tell the user those seats are gone. Expired holds are reclaimed by the same predicate, so no cleanup job is strictly required (one still helps keep the seat map accurate).
28	+
29	+	A Redis `SET seat:{e}:{s} order NX PX 480000` is a faster alternative for holds, but the database stays the source of truth for SOLD.
30	+
31	+	## Payment
32	+
33	+	Checkout calls the payment provider with an idempotency key. On success, flip HELD to SOLD in a transaction that checks the hold still belongs to this order. If the hold expired mid-payment, refund automatically.
34	+
35	+	## Handling the spike
36	+
37	+	- Virtual waiting room: put arriving users in a queue and admit them at a rate the booking service can handle. This is the single most important idea.
38	+	- Serve the seat map from a cache refreshed every second or two; it only needs to be approximately right because the hold step is authoritative.
39	+	- Rate-limit per user and use bot detection.
40	+
41	+	## Follow-ups
42	+
43	+	- General admission (no seat numbers): decrement a counter atomically instead of locking seats.
44	+	- Fairness: randomize queue position for people who arrived before the sale opened.
45	+
46	+	---
47	+	Disclosure: I'm part of [Linkjob AI](https://www.linkjob.ai/), an AI interview assistant.