What is System Design?
The Growth of a System: From Lemonade Stand to Global Scale
Imagine you open a lemonade stand. You have one pitcher and one cup. You serve one customer at a time. This is a Monolith.
But tomorrow, 1,000,000 people show up. You can’t just pour faster. You need a System.
Interactive: The Scale Slider
Adjust the slider to see how your architecture must evolve as traffic grows from a local stand to a global platform.
Phase 1: The Local Stand
A single pitcher (server) and cup (client). Simple, but has a SPOF.
Why This Matters
System Design is the bridge between “Code that works” and “Code that survives” (See Reliability Engineering).
- Junior Engineers write code that works on their laptop.
- Senior Engineers design systems that work when 10 million users hit the “Buy” button at the same time.
In your career, you will face two types of problems:
- Logical Problems: “How do I reverse a linked list?” (Algorithm)
- Architectural Problems: “How do I store 1 Petabyte of data?” (System Design)
This course is about solving the second type.
The Core Philosophy: Trade-offs over Solutions
A junior engineer asks: “What is the best database?” A senior engineer asks: “What are the read/write patterns?”
In System Design, there are no right answers, only trade-offs. Every decision you make to improve one variable usually degrades another.
Gold Standard: The Complexity vs. Performance Map
This diagram visualizes why we don’t always choose the most “powerful” system. Hover over the zones to see why.
Low Cost. High Speed for Small Teams.
Can handle 100M+ users. High Operational Overhead.
Explore the graph to understand the relationship between Complexity and Scale.
The 4 Quadrants of System Design
Every system is constrained by four fundamental resources. Your job is to balance them.
Why System Design is Hard: The Distributed Nightmare
When you move from one computer to two, you introduce a new demon: The Network. In a single computer (Monolith), function calls are fast. In a distributed system, we face the 8 Fallacies of Distributed Computing.
Click a fallacy below to reveal the reality:
The Scale Cube (AKF Scaling Cube)
To understand how we scale massive systems, we use the Scale Cube model.
- X-Axis: Cloning the app behind a Load Balancer.
- Y-Axis: Splitting the “Monolith” into Microservices.
- Z-Axis: Sharding the data based on a key (e.g., User ID).
Interactive: The Scale Cube Explorer
Deep Dive: The 12-Factor App Methodology
In modern distributed systems, we follow the 12-Factor App principles to ensure our apps are portable, scalable, and resilient.
[!NOTE] This methodology was created by Heroku engineers to solve the “it works on my machine” problem.
| Factor | Principle | Translation |
|---|---|---|
| 1. Codebase | One codebase tracked in revision control, many deploys. | One Git Repo per Microservice. |
| 2. Dependencies | Explicitly declare and isolate dependencies. | Use package.json or requirements.txt. No system installs. |
| 3. Config | Store config in the environment. | Use .env files. Secrets should NEVER be in Git. |
| 4. Backing Services | Treat backing services as attached resources. | The DB URL is just a config string. Swap MySQL for Postgres easily. |
| 5. Build, Release, Run | Strictly separate build and run stages. | Build an image (Docker). Deploy the image. Don't edit code on prod. |
| 6. Processes | Execute the app as one or more stateless processes. | No sticky sessions. Store state in Redis/DB, not in RAM. |
[!TIP] Factor 6 (Stateless) is the most critical for scaling. If your server holds user sessions in memory, you cannot auto-scale properly.
The Interview Gauntlet: Can you think in Trade-offs?
- “Why would I ever choose a Monolith over Microservices?”
- Ans: Faster development for small teams, zero network overhead, simpler debugging.
- “How does Z-Axis scaling differ from X-Axis scaling?”
- Ans: X-Axis scales request processing (CPU), Z-Axis scales data storage (Disk/RAM).
- “What is the biggest downside of Vertical Scaling?”
- Ans: The “Ceiling” (Physical hardware limits) and the high cost of high-end hardware.
- “What does ‘Stateless’ mean in the context of the 12-Factor App?”
- Ans: The app does not rely on local memory to store data between requests. Any request can be handled by any server.
- “If Microservices are so great, why did Segment revert to a Monolith?”
- Ans: Because the overhead of serializing/deserializing and network hops between 100+ services outweighed the benefits. Complexity cost > Scalability gain.
- “Is it possible to have infinite horizontal scaling?”
- Ans: No. Eventually, you hit a bottleneck in the shared resource (e.g., the Load Balancer, the Database, or even the Network switch).
[!IMPORTANT] Summary: System Design is not about memorizing patterns; it’s about defending trade-offs. Always start by asking about the constraints before proposing a “Global Distributed System”.
Summary
- Trade-offs: Every architectural decision has a cost.
- Scale Cube: X (Cloning), Y (Services), Z (Sharding).
- Fallacies: The network is unreliable, slow, and insecure. Design defensively.
- 12-Factor: Build stateless, config-driven apps.
- Start Simple: Don’t build microservices for 100 users.
[!WARNING] Trap: Do not suggest Microservices immediately in an interview unless the scale justifies it. It introduces massive operational complexity (Network latency, distributed tracing, eventual consistency).
Next: Learn how to define what your system should do in Functional vs. Non-Functional Requirements.