Overview

Friday, 10:00. BoxOffice, a small ticketing start-up, opens the sale for the year's biggest stadium show: 60,000 seats, 2 million fans refreshing the page at the same second. At 10:00:04 the site answers in 9 seconds. At 10:00:20 it answers nothing. At 10:03 it comes back — and 312 seats have been sold twice. The code had no bug that a unit test could catch: every function did exactly what it was written to do. What failed was the system: how many machines, which database, where the data lives, what waits for what, and what happens when 2 million people arrive at once.

This course is about that layer — the decisions that sit above the code and decide whether the code survives contact with reality. By the end of the semester you will be able to design BoxOffice so that 10:00 on Friday is a non-event, measure that it works, and defend every decision with numbers, in a design review or in a system-design interview.

Roadmap

1. This overview — what system design is, the component palette that organizes the course, and how to use the playground.
2. Requirements — functional vs non-functional requirements; the quality attributes and how to make them measurable.
3. The Scaling Journey — BoxOffice from 1 user to 10 million: monolith first, then one component per symptom.
4. The Interview Framework — a 7-step, 45-minute method for open-ended design problems.
5. Quiz — check your understanding.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

What is system design?

System design is the process of defining the components of a system, the interfaces between them, and the data that flows through and is stored by them, so that the system satisfies its requirements — both what it must do and how well it must do it¹. It answers questions like:

• How many servers do we need, and what happens when one dies?
• Where does each piece of data live, who is allowed to change it, and how fast must every reader see the change?
• Which work must happen now, while the user waits, and which can happen later?
• What will this cost per month, and what breaks first if traffic doubles?

It is useful to place system design next to the design work you already know:

The jump from software design to system design is a jump from one process to many processes on many machines, connected by an unreliable network. That jump brings three new realities:

1. Load — the system must keep working when many users arrive at once. Ten users and ten million users need different architectures, not just more of the same.
2. Partial failure — some parts fail while others keep running. A disk fills, a node reboots, a third-party API slows down. The system must keep its promises anyway.
3. Trade-offs — almost every decision buys one quality with another. A cache buys latency with freshness; a replica buys availability with consistency; a queue buys resilience with immediacy.

Why it matters to you

• At work, almost every feature eventually raises a system question: Will this query be fast with 50 million rows? Should this e-mail be sent synchronously? What happens if the payment provider is down? Engineers who can answer with numbers make better decisions and are trusted with bigger ones.
• In interviews, system design is a standard round for software engineering roles at most technology companies. It is open-ended on purpose: the interviewer watches how you think — how you clarify, estimate, structure, and handle trade-offs².
• In this course, it is the thread that ties together everything from DNS to AI agents: each topic is a component you add to a design for a reason you can measure.

BoxOffice, the running example

Every class, lab, quiz and slide deck uses the same fictional system, so that each new concept lands on a problem you already know. BoxOffice sells tickets for concerts, games and festivals. It was chosen because it has, on purpose, every hard property a real system can have — and they are intuitive:

Its services — which you will build, measure and break in the labs — are gateway, auth, catalog (events and venues), inventory (seats and holds), order, payment (adapter to an external provider), notification, search and assistant (AI). The code lives in the course repository, https://github.com/repo-classes/pma271.

This is where BoxOffice is heading by the end of the semester. Press play to follow a purchase through it:

flowchart LR
    fan([Fan]) --> cdn["CDN"]
    fan --> waf["WAF"]
    waf --> gw["API Gateway"]
    gw --> auth["auth"]
    gw --> catalog["catalog"]
    catalog --> cache[("Cache")]
    cache --> catdb[("SQL")]
    gw --> wr["Waiting room<br/>(queue)"]
    wr --> inventory["inventory"]
    inventory --> invdb[("SQL<br/>seats & holds")]
    inventory --> order["order"]
    order --> payment["payment"]
    payment --> psp["Payment provider<br/>(external)"]
    order --> kafka["Event stream"]
    kafka --> notification["notification"]
    notification --> email["Email / push"]

You do not need to understand every box today. The point of the course is that, by week 15, you will be able to explain why each box is there, what number would make you remove it, and what you would add next.

The component palette

Real architectures are assembled from a surprisingly small set of building blocks. The course is organized around a component palette — the same palette the course simulator uses. Each theory class teaches one group of components: what each one does, when to use it, when not to, the numbers that describe it, and how it fails.

The other classes are cross-cutting: they do not add boxes, they give you the tools to reason about all of them.

flowchart TB
    subgraph F["Foundations"]
        direction LR
        c1["1. Intro &<br/>interview framework"] --> c2["2. Estimation &<br/>performance math"] --> c3["3. Distributed<br/>systems"]
    end
    subgraph P["The palette, one group per class"]
        direction LR
        c4["4. Edge"] --> c5["5. Compute"] --> c6["6. Databases"] --> c7["7. Caching"] --> c8["8. Messaging"]
    end
    subgraph O["Running it in production"]
        direction LR
        c9["9. Reliability"] --> c10["10. Observability"] --> c11["11. Network &<br/>security"] --> c12["12. Cloud-native"]
    end
    subgraph X["Putting it together"]
        direction LR
        c13["13. AI systems"] --> c14["14. AI-assisted<br/>delivery"] --> c15["15. Performance &<br/>load testing"] --> c16["16. Case studies"]
    end
    F --> P --> O --> X

Each component has an entry in the component catalog — for example Load Balancer, Cache or Message Queue — with a one-line interview definition, key numbers, failure modes and the real products (AWS, GCP, Azure, open source) that implement it. Use it as a dictionary while you read.

The System Design Playground

Reading about a cache is not the same as watching the p99 latency fall when its hit ratio climbs. The course comes with a simulator, the System Design Playground, where every component of the palette is a block you can drop on a canvas, connect, and put under load. It is a model — it does not run real code — but it reproduces the behaviour that matters for design: queues that grow when a component is saturated, latency that explodes near full utilization, failures that cascade when there are no timeouts, cost that grows with every replica.

The workflow is always the same:

1. Build — pick components from the palette and connect them (client → load balancer → app → database…).
2. Configure — set capacities, replicas, cache hit ratios, timeouts.
3. Load — choose a load profile: smoke (a trickle, to check it works), load (expected traffic), stress (beyond it), spike (a sudden jump, like 10:00 on Friday), soak (hours at a steady rate), breakpoint (ramp until something breaks), chaos (inject failures).
4. Read — watch throughput, latency percentiles (p50, p99), error rate, per-component utilization and monthly cost.
5. Change one thing and run again. That is the scientific method applied to architecture, and it is exactly what you will do with real systems in the labs.

Throughout the course, pages embed the playground preloaded with a scenario. Here is the first one: BoxOffice as a single application server and a single SQL database.

Try it: start with the load profile and note the p99 latency and the utilization of the app and the database. Then switch to spike. Which component saturates first? What happens to latency before errors appear? Write down the request rate at which things went wrong — you will compute it by hand in class 2.

The second scenario puts a load balancer in front of several replicas of the application.

Try it: run the stress profile with 1 replica, then 2, then 4. Does throughput double each time? Watch the database: at some point adding app replicas stops helping. Why? Then kill one replica (or use the chaos profile) and watch what the health checks do.

The intro concept map

This class touches the whole palette lightly: every quality attribute (blue) is bought with some palette components (green), and the scaling journey adds them one measured symptom at a time. Use the map as an index to the rest of the course:

flowchart LR
    client["client · mobile"]:::comp --> req["requirements:<br/>functional + quality attributes"]:::tech
    req --> scal["scalability"]:::tech
    req --> lat["latency"]:::tech
    req --> avail["availability"]:::tech
    req --> cons["consistency,<br/>durability"]:::tech
    req --> sec["security"]:::tech
    req --> ops["operability"]:::tech
    scal --> c1["lb · app replicas ·<br/>queue · worker · nosql"]:::comp
    lat --> c2["cache · cdn"]:::comp
    avail --> c3["healthcheck · dns failover"]:::comp
    cons --> c4["sql · objstore"]:::comp
    sec --> c5["waf · apigw · auth"]:::comp
    ops --> c6["metrics · logs · tracing"]:::comp
    classDef comp fill:#1e9e5a22,stroke:#1e9e5a
    classDef tech fill:#2f6fed22,stroke:#2f6fed

How to study system design

• Draw. Every concept in this course has a picture. If you cannot draw it, you do not understand it yet.
• Estimate before you design. A design for 100 requests per second and one for 100,000 are different designs. Class 2 gives you the numbers and formulas.
• Name the trade-off. For every component you add, say what it buys and what it costs: "the cache cuts catalog p99 from 80 ms to 5 ms, at the price of showing a price up to 60 s stale".
• Break things on purpose. In the playground and in the labs, find the breaking point, then fix it. You learn more from one saturation than from ten diagrams.
• Practise out loud. System design is a conversation. Use the interview framework with a classmate every week, starting now.

Related

• Hands-on: 0. Environment (tools and the course repository) and 1. First service (the catalog API).
• Exercise: Playground design — solve playground challenges against SLO and cost goals.
• Case study: Ticketing — the BoxOffice flash sale, the full design of the system introduced here.
• Interview: Interview framework and practice problems.

Key takeaways

What breaks next

The requirements now have numbers — 2 million fans in the first minute, 60,000 seats, hold p99 < 300 ms, checkout available 99.95% of the time — but nobody has checked them against the single PostgreSQL that BoxOffice runs on. Whether it takes the 10:00 on-sale is not a matter of opinion, it is arithmetic: requests per second, the time one hold keeps the database busy, how full it can run before latency explodes. Doing that arithmetic, and finding ~33,000 hold attempts/s against ~1,100 that one database sustains, is class 2 — Estimation.