System Architecture — 2027.1

Most systems you will build or maintain in your career have to be fast, available, consistent enough, secure and affordable — at the same time, under load, while parts of them fail. This edition of the course is about how to design such systems, how to prove with numbers that a design works, and how to explain it — to a team in a design review, and to an interviewer in a system-design interview.

The running example: BoxOffice

A stadium show goes on sale at 10:00. Two million fans, sixty thousand seats. The catalog is read-heavy, the seat inventory must never sell the same seat twice, payments go through an external provider that sometimes slows down, confirmations go out by e-mail, bots try to buy everything, and an AI assistant answers "find me two seats under R$ 300 for Saturday and hold them". Almost every topic of the course appears in this one system.

flowchart LR
    U["fans<br/>(web, mobile)"] --> DNS["DNS"] --> CDN["CDN"] --> WAF["WAF"] --> GW["API gateway"]
    GW --> AUTH["auth"]
    GW --> CAT["catalog"] --> CACHE[("cache")]
    CACHE --> SQL[("SQL")]
    GW --> Q["waiting room<br/>(queue)"] --> INV["inventory<br/>(seat holds)"] --> SQL
    INV --> ORD["order"] --> PAY["payment"] --> EXT["payment provider"]
    ORD --> K["event stream"] --> NOTIF["notification"] --> MAIL["e-mail"]
    K --> AN["analytics / DWH"]
    GW --> AI["assistant<br/>(LLM gateway, tools, RAG)"]

The story of the course

The classes are not a list of topics: they are the chapters of one story. BoxOffice starts as one service and one database, and every chapter begins with the problem the previous one left, stated with a number. A component enters the design only when a number asks for it, and each one brings a new problem. Press play to follow the chain:

flowchart TD
    C1["1. What must BoxOffice do, and how well?"] -->|"2 M fans, 60 k seats, p99 < 300 ms:<br/>is one database enough?"| C2["2. Estimate before you build"]
    C2 -->|"33,000 holds/s against ~1,100:<br/>we need more than one machine"| C3["3. More machines, a network that lies"]
    C3 -->|"replicas exist: who receives<br/>the 2 M requests at 10:00?"| C4["4. Traffic, edge & identity"]
    C4 -->|"the edge spreads load over replicas:<br/>what must a replica be?"| C5["5. Compute & services"]
    C5 -->|"stateless services push all<br/>state into the database"| C6["6. Databases"]
    C6 -->|"the event pages are read 100× more<br/>than they change"| C7["7. Caching"]
    C7 -->|"checkout still waits<br/>for the e-mail provider"| C8["8. Messaging"]
    C8 -->|"asynchrony hides failures:<br/>where did that order go?"| C9["9. Observability"]
    C9 -->|"now we see it: the provider answers<br/>in 4 s and drags checkout down"| C10["10. Reliability"]
    C10 -->|"a laptop with Compose cannot heal,<br/>scale or deploy safely"| C11["11. Cloud-native platforms"]
    C11 -->|"many services on one platform:<br/>who may talk to whom? what do we ship?"| C12["12. Network & security"]
    C12 -->|"fans ask in plain language:<br/>'two seats under R$ 300, Saturday'"| C13["13. AI systems"]
    C13 -->|"more changes, faster:<br/>who reviews, tests, releases?"| C14["14. AI-assisted delivery"]
    C14 -->|"does the whole design hold<br/>the next on-sale? prove it"| C15["15. Performance engineering"]
    C15 -->|"the same blocks, other systems"| C16["16. Case studies"]

Each row of the table is one chapter: the problem that opens it, the class that answers it, the lab where you build the answer in BoxOffice (and the file to read first), and the playground scenario where you can see it fail and recover. The planning puts the chapters on the calendar.

Map of the course

The week-by-week plan is on the planning page.

Meetings

Instructors

Grade

1. Exercises (individual): seven exercises — estimation, load-test report, cache & database, event-driven, Kubernetes autoscaling, playground design and design doc — each graded with a concept (A–I) and a rubric. Weights and rules are on the exercises page.

2. Quizzes: three quizzes; the lowest is dropped and the grade is the average of the two best:

   \[ \text{Quizzes} = \frac{\text{Q}_1 + \text{Q}_2 + \text{Q}_3 - \min(\text{Q}_1, \text{Q}_2, \text{Q}_3)}{2} \]

3. Exams: a midterm and a final exam, individual, covering the classes and the labs. Part of each exam is a short system-design question in the format of the interview framework.

4. Team project: teams of 2 or 3 students build, measure, break on purpose and defend one system, in nine milestones (design doc, core path, scale & cache, async & resilience, Kubernetes + CI/CD, load-test campaign, chaos game day, cost report, presentation). The team grade is the same for all members. Details on the project page.

   Team registration

   Deadline: end of week 3 (date on the planning page).

   Teams from 2 up to 3 members, one GitHub repository per team, documentation on GitHub Pages.

Repositories

Course repository (code of the labs and starters): repo-classes/pma271 (to be published).