Tonight's interview shape is the first system-design conversation: a small service gets popular, one machine starts struggling, and the interviewer wants to hear how you think before any code exists. The win is not naming fancy tools. The win is drawing the boxes, finding the bottleneck, and saying the trade-off clearly.
The invariant
You scale up with a bigger box or out with more boxes; once data lives on more than one box, a network partition forces the CAP choice between consistency and availability.
That sentence is the whole lesson. App servers are usually easy to clone because they should be stateless. Data is harder: the moment two machines can answer for the same data, the network between them becomes part of the correctness story.
The script
Use the same seven steps every time: requirements → estimate scale → API → data model → high-level boxes → deep-dive the bottleneck → failure modes. For scaling basics, apply it like this:
Requirements: users can read items and create orders; reads should feel fast, writes should not lie.
Estimate scale: separate read traffic from write traffic; reads usually grow first and are easier to cache.
API: sketch simple endpoints such as GET /items/:id and POST /orders.
Data model: name the core tables or documents: users, items, orders.
Notice the order. You do not start with Kafka, Kubernetes, or ten databases. Start with the user promise, then add machinery only where the pressure appears.
The architecture diagram
The interesting line is not the load balancer. It is the broken link between data copies.
The bottleneck deep-dive
The database is the bottleneck because it owns truth. Three named choices cover most beginner scaling answers:
Scale up: buy a bigger database box. This keeps one source of truth and the simplest consistency story, but it has a ceiling and gets expensive.
Scale out reads: add replicas and route read-heavy traffic to them. Latency improves, but replicas can lag behind the primary.
Partition the data: shard by user, region, or item id. Capacity grows, but queries across shards and cross-shard transactions get harder.
CAP appears only when a partition happens. If the primary and replica cannot talk, a consistent design waits, rejects, or routes to the side that knows the latest write. An available design answers from whatever side is reachable, then accepts that the answer may be stale and needs repair later. The formal CAP result is about this partition moment, not a magic excuse for every slow system (CAP theorem overview).
Numbers that matter
Figure
Why it matters
Source
100 ms
Feels roughly instant to a user; great target for common reads.
The table is not for memorizing trivia. It teaches the interview habit: turn vague words like “fast” and “reliable” into rough numbers before choosing boxes.
Practice — answer before you scroll past
1. A single database box is near CPU limit. Which first move preserves the simplest consistency story?
Scaling up keeps one authoritative database, so the consistency story stays simple. It does not scale forever, but it is the clean first trade-off to name.
2. During a network partition, what does CAP force you to choose between?
When messages between data copies are dropped or delayed, the system can wait to protect consistency or answer to protect availability.
3. Which design makes reads fast but risks stale data?
A cache can answer repeated reads quickly, but its copy may be older than the database unless invalidation or expiration is handled carefully.
4. For a beginner design answer, what is the safest order?
The course script starts with what the system must do, then estimates pressure, then draws boxes, then examines the bottleneck and failure modes.
Your move (tonight)
No LeetCode for this lesson. Redraw the architecture diagram from memory on paper, then explain the whole design out loud in 5 minutes as if to an interviewer. Use this exact spine: requirements → estimate scale → API → data model → high-level boxes → deep-dive the bottleneck → failure modes.
For the encode step, write one line in your Notion tracker: where you would scale up, where you would scale out, and what you would do during a database partition.
One primary source
Read System Design Primer — Scalability after your redraw, as the compare step. Find the first place where its trade-off language is sharper than yours.