Running a 45-minute system design round

Meta’s guide gives its design interview 45 minutes and says the question “will be something very high-level and it will be up to you to drive the conversation.” Nobody designs a whole system in 45 minutes; the round scores where you spend them, and whether the interviewer can follow you from the first requirement to the last trade-off.

Here the minutes are laid out block by block on an original prompt, ticket sales for a college festival, with the estimates worked out by a program you can run and the order that keeps the interviewer with you.

A 45-minute plan, and the order that keeps the interviewer with you

Seven blocks cover a round: 5 minutes of requirements, 3 of estimates, 5 for the API, 5 for the data model, 12 for the high-level design, 12 for deep divesdeep dive: The part of a design round in which you take one component of your design in detail, with its data, its failure cases and the trade-offs of each choice. and 3 to wrap up (MySmartCoPilot’s recommendation). Walk through them:

The order is the point. Each block hands the next what it needs: the requirements say what to estimate, the estimates say which part is hard, the API and the data model say what the boxes must serve, and the deep dives go where the numbers pointed. Amazon’s SDE III page asks for the same habits: treat the interviewer as a customer, note your assumptions, and ask what twice or ten times the growth would do to the design.

Here are the estimatesback-of-the-envelope estimate: A quick calculation in round numbers, such as requests a second, writes a second or gigabytes of data, made to find out which parts of a design will be hard. for the festival prompt, three concert nights of 4,000 seats, 30,000 students who may buy up to two tickets each, and sales that open at six in the evening:

"""Back-of-envelope estimates for the festival ticketing prompt, and what each one decides."""

STUDENTS = 30_000  # who may buy
NIGHTS, SEATS_PER_NIGHT = 3, 4_000
MAX_PER_BUYER = 2
ARRIVE_SHARE = 0.6  # share of students who try in the first two minutes
ARRIVE_SECONDS = 120
REQUESTS_PER_BUYER = 6  # event page, seat map, hold, pay, confirm, ticket
WRITES_PER_BUYER = 2  # the hold and the payment confirmation
PEAK_FACTOR = 2  # the first 30 seconds run at twice the average
TICKET_BYTES, BUYER_BYTES = 500, 1_000

seats = NIGHTS * SEATS_PER_NIGHT
buyers = round(STUDENTS * ARRIVE_SHARE)
peak_requests = buyers * REQUESTS_PER_BUYER / ARRIVE_SECONDS * PEAK_FACTOR
peak_writes = buyers * WRITES_PER_BUYER / ARRIVE_SECONDS * PEAK_FACTOR
asked = buyers * MAX_PER_BUYER
storage_mb = (seats * TICKET_BYTES + STUDENTS * BUYER_BYTES) / 1_000_000

print(f"{'seats on sale':<28}{seats:>8,}")
print(f"{'buyers in the first 2 min':<28}{buyers:>8,}")
print(f"{'requests a second, peak':<28}{peak_requests:>8,.0f}")
print(f"{'writes a second, peak':<28}{peak_writes:>8,.0f}")
print(f"{'seats asked for':<28}{asked:>8,}  ({asked / seats:.1f} per seat)")
print(f"{'data to store':<28}{storage_mb:>5.0f} MB")
print()
print(
    f"- {peak_requests:,.0f} requests a second: a few app servers, one load balancer."
)
print(f"- {peak_writes:,.0f} writes a second on {seats:,} seat rows: one database.")
print(
    f"- {asked / seats:.0f} seats asked for each seat sold: fairness is the hard part,"
)
print("  so the deep dives go to the queue and the holds, not to throughput.")

seats on sale                 12,000
buyers in the first 2 min     18,000
requests a second, peak        1,800
writes a second, peak            600
seats asked for               36,000  (3.0 per seat)
data to store                  36 MB

- 1,800 requests a second: a few app servers, one load balancer.
- 600 writes a second on 12,000 seat rows: one database.
- 3 seats asked for each seat sold: fairness is the hard part,
  so the deep dives go to the queue and the holds, not to throughput.

Three minutes of arithmetic move the whole round. At 1,800 requests a second at the peak and 600 writes a second on 12,000 seat rows, one database is enough, so sharding never needs a minute; three seats asked for each seat on sale make fairness the hard part, so the deep dives go to the queue and the holds.

Design rounds also come in more than one kind. A systems design round weighs distributed systems, scale and performance, while a product architecture round weighs the API, data ownership and the client-server design.

The festival round, minute by minute, with the interviewer’s notes Pro: opens with a Pro, Premium or Ultimate pass