Section 3: Fifty Fans Per Seat - Scale Estimation & Workload Analysis

Executive Summary: This section derives two workloads that look like different systems. A normal day is about 6.3 orders a second and 25 GB of live inventory: one ordinary database could carry it. The stadium on-sale for show E-7781 is 3,000,000 fans for 60,000 seats and a potential 3,000,000 requests a second, 150 times the backend's design load. The arithmetic then shows where that load can go: the edge, a 67-per-second admission rate, 200 to 1,000 holds a second, and a 7.5 KB seat bitmap. The hot show's whole inventory is 6 MB. The problem is contention and admission, not size.

The interviewer has your requirements from Section 2 on the board and asks the obvious question: "How big is this thing?" The honest answer is "it depends which minute you mean," so derive both minutes and let the gap make the argument.

A Normal Day

Start from yearly ticket volume and work down. Say each assumption aloud so the interviewer can correct it.

Tickets sold:      500M per year ÷ 365              ≈ 1.37M tickets/day
Orders:            1.37M ÷ 2.5 tickets per order    ≈ 548,000 orders/day
Average rate:      548,000 ÷ 86,400 s               ≈ 6.3 orders/s
Evening peak 3×:   6.3 × 3                          ≈ 19 orders/s
Browsing:          100M MAU × 10 page views/month   = 1B views/month
                   1B ÷ 30 ÷ 86,400 s               ≈ 386 ≈ 400 page views/s

Storage is just as modest:

Live inventory:    50,000 active events × 5,000 seats = 250M seat rows
                   250M × 100 B                        ≈ 25 GB
Orders:            548,000 × 2 KB                      ≈ 1.1 GB/day ≈ 400 GB/year
Tickets:           1.37M × 500 B                       ≈ 685 MB/day ≈ 250 GB/year

Interviewer: "Six orders a second and 25 GB. One Postgres box and we're done?"

You: "For the average day, yes, and I'd say so. But nobody calls this a hard problem because of the average day. Ticketing traffic isn't spread across the year. It arrives in on-sale spikes, so the number I have to design for is the worst ten minutes, not the mean."

Key Insight: An average day is about 6 orders a second. If your design is sized from that number, it is sized for a system nobody would interview you about. The average sets the storage budget; the on-sale sets the architecture.