Foundations of System Design
Before we talk about load balancers and databases, let's build the mental model: what a "system" is, how requests flow through it, and how we decide what "good" looks like.
- Explain what system design is and why it matters
- Trace a request from browser to server and back
- Tell functional from non-functional requirements
- Name the core qualities systems are judged by
- Use a repeatable framework for any design problem
What is system design?
System design is the process of deciding which components a software system needs, how they connect, and how data flows between them — so the system meets its goals for features, speed, reliability and cost.
Writing code answers “how do I implement this function?”. System design answers bigger questions: “what happens when 10 million people use this at once? What if a server dies at 3am? Where does the data live?”
Cooking dinner for yourself needs one person and one stove. Serving 500 guests a night needs a head chef, line cooks, a pantry, a queue of orders, and a plan for when the fryer breaks. Serving 5 million meals a day across 1,000 locations needs central warehouses, standardized recipes and delivery logistics. The food is the same — the system around it is completely different. That's system design.
Watch a system grow
Almost every large system started as one server. Components get added only when a real problem appears. Drag through the stages below — each stage solves one problem and introduces a new one.
Don't design for 100 million users on day one. Good system design is about solving today's problems while leaving room for tomorrow's. Over-engineering costs money and time just like under-engineering does.
The client–server model
Nearly every system you'll design follows one basic pattern: a client asks for something, a server does the work and answers. That's it. Everything else is detail layered on top.
Client
Initiates requests. Browsers, mobile apps, smart TVs — or even another server calling an API.
Server
Listens for requests, runs business logic, reads/writes data and sends back a response.
Request / Response
The conversation. Usually HTTP: “GET /profile/42” → “200 OK + JSON data”.
“Client” and “server” are roles. Your web server is a server to the browser but a client to the database. In big systems, most machines play both roles at once.
What happens when you open a website?
Let's trace a single request end-to-end. This is one of the most famous interview questions — and it touches nearly every topic in this course. Step through it:
- The browser parses the URL into parts: protocol
https, hostshop.com, path/products. It checks its own caches first — maybe it already knows the answer. - Computers talk using IP addresses, not names. The browser asks DNS: “what's the IP for shop.com?” and gets back
93.184.216.34. (Chapter 2 zooms into this.) - The browser opens a TCP connection to that IP (a quick “handshake”) and then negotiates TLS encryption — that's the S in HTTPS.
- Over the connection it sends:
GET /products HTTP/1.1plus headers like cookies and accepted languages. - The server runs application code: authenticate the user, then query the database:
SELECT * FROM products LIMIT 20. - The database finds the rows (using an index — Chapter 7) and returns them to the server.
- The server builds a response —
200 OKwith HTML or JSON — and sends it back over the same connection. - The browser parses HTML, fetches CSS/JS/images (often from a CDN — Chapter 6) and paints the page. All of this usually takes under a second.
Requirements: what are we actually building?
Every design starts with requirements, and they come in two flavours. Mixing them up is the #1 beginner mistake.
🛠️ Functional requirements
What the system does. Features and behaviours a user can see. Usually phrased as “users can…”.
“Users can upload a video.”
“Users can comment on a post.”
📏 Non-functional requirements
How well the system does it. Qualities like speed, uptime, scale, durability and security.
“Videos start playing within 2 seconds.”
“The service is available 99.99% of the time.”
Non-functional requirements drive the architecture. “Users can send messages” could be built a hundred ways; “deliver messages to 500M users in under 100ms” rules out most of them. Always ask about scale, latency and availability before drawing anything.
The qualities every system is judged by
These are the “-ilities” you'll hear constantly. Click each card to flip it.
Scalability
click to flipAvailability
click to flipReliability
click to flipLatency
click to flipThroughput
click to flipConsistency
click to flipDurability
click to flipMaintainability
click to flipEverything is a trade-off
There is no perfect architecture. Every decision buys you something and costs you something else. Learning system design is really learning the trade-offs — and being able to explain why you picked one side.
| You gain… | …but you pay with | Example |
|---|---|---|
| ⚡ Lower latency | Stale data risk | Caching a profile for 5 minutes |
| 🟢 Higher availability | Weaker consistency | Letting replicas answer reads during a network split |
| 📈 Horizontal scale | Operational complexity | Splitting a monolith into 40 microservices |
| 💾 Durability | Write latency & cost | Waiting for 3 replicas to confirm every write |
| 🧩 Flexibility (schemaless) | Query power & integrity | Choosing a document DB over SQL |
A framework for any design problem
Whether it's an interview or a real project, this sequence keeps you from getting lost. Every case study in this course follows it.
Clarify requirements ~5 min
Functional features in scope, non-functional goals (scale, latency, availability), and what's explicitly out of scope.
Estimate the scale ~5 min
Back-of-envelope: users, requests per second, storage per year, read/write ratio. Chapter 4 teaches this math.
Define the API & data model ~5 min
What endpoints exist? What entities and relationships? This pins down the contract before the plumbing.
High-level design ~10 min
Draw the boxes and arrows: clients, load balancers, services, databases, caches, queues. Walk a request through it.
Deep dive ~15 min
Zoom into the hardest 1–2 parts: the hot path, the data partitioning, the consistency story.
Bottlenecks & trade-offs ~5 min
What breaks first at 10× traffic? What are the single points of failure? What did you trade away and why?
- Designing before scoping. Drawing boxes in minute two, then discovering the system only has 10,000 users and none of it was needed.
- Treating non-functional requirements as an afterthought. “Fast” and “reliable” aren't requirements; “p99 < 200 ms” and “99.9% availability” are, and they change the architecture.
- Confusing the client–server boundary. Putting trust, validation or secrets in the client because “our app controls it”. Anything the client sends is attacker-controlled input.
Warm-up: A colleague says “we need a scalable system”. What three questions do you ask before agreeing to anything?
How a strong answer sounds
Explain it simply: Walk through what happens between pressing Enter on a URL and seeing the page.
How a strong answer sounds
🧠 Key takeaways
- System design is choosing components, connections and data flow to meet goals for features, performance, reliability and cost.
- Systems evolve: add a component only when a real problem demands it.
- Client and server are roles — most machines in a big system are both.
- Functional requirements = what it does. Non-functional = how well. NFRs shape the architecture.
- There are no right answers, only trade-offs you can justify.
Check your understanding
Which of these is a non-functional requirement?
Your single server runs the app and the database. It's running out of CPU and memory. What's the most sensible first step?
A web server queries a database. In that interaction, the web server is acting as a…
A service is “up” 100% of the time, but 2% of responses contain another user's data. Which quality is it failing?
In a design interview, what should you do FIRST?