What Is System Design?
An introduction to system design: what it is, why it matters in software engineering, and how it is evaluated in technical interviews.
What Is System Design?
System design is the process of defining the architecture, components, interfaces, and data flows of a system to satisfy a set of requirements. It sits above the level of individual algorithms and data structures — instead of asking 'how do I sort this list?', system design asks 'how do I build a service that stores and retrieves billions of user records reliably and at low latency?'
In practice, every non-trivial software product is the result of dozens of intertwined system design decisions: which databases to use, how services communicate, where data is cached, how failures are handled. Engineers who reason well about these decisions build products that scale, survive outages, and evolve gracefully.
The System Design Spectrum
System design spans a wide range of problems. At one end you have low-level design (class structure, API shape, data models for a single service). At the other end you have high-level design (how dozens of microservices, databases, and queues fit together to serve millions of users). Interview rounds typically focus on the high-level end, which is what this course addresses.
Why System Design Matters in Interviews
For senior and staff-level engineering roles, system design is often the most important interview signal. A strong algorithmic interview shows you can implement; a strong system design interview shows you can architect. Companies like Google, Meta, Amazon, and Netflix run dedicated system design rounds for this reason.
The ability to design systems also correlates strongly with on-the-job impact. Engineers who understand distributed systems fundamentals make better decisions at every layer — from database schema choices to API design to capacity planning.
How Interviews Are Evaluated
While rubrics vary by company, most interviewers evaluate system design across five dimensions:
| Dimension | What the Interviewer Is Looking For |
|---|---|
| Problem Scoping | Do you clarify requirements before designing? Do you identify scale, constraints, and non-functional requirements? |
| High-Level Design | Can you decompose the problem into coherent components? Is the architecture logical and complete? |
| Deep Dives | Can you reason about a specific subsystem (e.g., the database layer, caching strategy) in detail? |
| Trade-Off Reasoning | Do you acknowledge alternatives and explain why you chose one approach over another? |
| Communication | Is your explanation structured, clear, and collaborative? Do you listen to hints and adapt? |
A Framework for Every Interview
Experienced system design interviewers follow a structured flow. Memorizing this structure prevents the common mistake of jumping straight into drawing boxes without understanding the problem.
- Clarify requirements — Ask about users, scale, consistency needs, read/write ratios, latency targets.
- Estimate scale — Back-of-the-envelope: QPS, storage, bandwidth. This drives every architectural decision.
- Define the API — What endpoints or interfaces does the system expose? What are the inputs and outputs?
- High-level design — Draw the major components and how data flows between them.
- Deep dive — Pick 1-2 critical subsystems and go deep: database schema, caching strategy, failure handling.
- Identify bottlenecks — Where are the hotspots? How would you scale or make this more resilient?
- Wrap up — Summarize trade-offs, discuss what you would do differently given more time.
Interview Tip
Start every interview by asking 3-5 scoping questions before touching the whiteboard. This demonstrates seniority, prevents wasted effort, and buys time to think. Good questions include: 'How many daily active users?', 'What are the latency requirements?', 'Should I optimize for read or write throughput?', and 'Are there any geographic distribution requirements?'
Common Mistakes to Avoid
- Jumping to solutions — Picking a database or framework before understanding requirements.
- Premature optimization — Adding sharding or global replication before establishing base load.
- Ignoring failure modes — Designing the happy path only, without addressing what happens when components fail.
- Silence — Thinking without narrating. Interviewers can only evaluate what they can hear.
- No trade-offs — Presenting your design as the only correct answer. Every design has downsides.
- Missing the data model — Forgetting to think about how data is actually stored and queried.
Think out loud
The interviewer is your collaborator, not your judge. Narrate your reasoning as you work. Say things like 'I'm going to start with a simple approach and then identify bottlenecks' or 'I'm choosing PostgreSQL here because the data is relational and consistency matters — but if we need to scale writes dramatically, we might reconsider.' This collaborative style is how senior engineers actually work.
Building the Foundation
The remaining lessons in this module cover the fundamental concepts that appear in virtually every system design interview: scalability strategies, reliability and availability, the CAP theorem, consistency models, SLAs/SLOs/SLIs, and estimation. Master these, and you will have a vocabulary and mental framework for any system design problem you encounter.
No single right answer
Every system design question has multiple valid solutions. Netflix and YouTube both serve video at massive scale but have very different architectures. Your goal is not to reproduce a specific company's architecture — it's to demonstrate that you can reason through constraints and make principled decisions.