Chapter 01 — What is System Design? (And Why Interviews Love It)
Chapter 01 — What is System Design? (And Why Interviews Love It)
Hey everyone! Welcome to Namaste System Design! 🙏
Take a deep breath. You've probably seen those scary interview stories — "Design Instagram in 45 minutes" — and thought system design is some dark art only ex-Google architects understand. That's a myth. By the end of this chapter you'll see that system design is just drawing boxes and arrows, and honestly explaining your trade-offs. If you can explain why you'd take the stairs instead of a broken lift, you can learn system design.
So let's start with the most honest question of all... "What even IS system design?"
What we will cover:
- What "system design" actually means (in plain English)
- HLD vs LLD — the two altitudes of design
- Why one single server is never enough
- The 4 forces every system fights: scale, speed, safety, cost
- Functional vs non-functional requirements
- Why there is no "correct" answer — only trade-offs
- How to think like a designer, not just a coder
- Common misconceptions beginners have
- Interview Questions
1. A Small Story First
Imagine you open a tiny tea stall — Sharma Ji's Chai. 🍵
Day 1: it's just you. One stove, one kettle, one cup at a time. Five customers a day. Life is beautiful.
Then a food blogger posts about you. Suddenly 500 people show up. One stove can't boil fast enough. The queue is out the door. People leave angry. You're losing customers not because your chai is bad — but because your system can't handle the load.
┌─────────────────────────────────────────────────────────────┐ │ SAME CHAI, DIFFERENT SCALE │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 5 CUSTOMERS ☕ 500 CUSTOMERS 🔥 │ │ ───────────── ─────────────── │ │ 1 stove → fine 1 stove → meltdown │ │ 1 person → relaxed 1 person → drowning │ │ "no system needed" "I need a SYSTEM" │ │ │ └─────────────────────────────────────────────────────────────┘
To survive, you add more stoves, a person who only takes orders, another who only collects money, and you pre-boil milk during rush hour. Congratulations — you just did system design. You reorganized parts so the whole thing survives more load.
Software system design is exactly this — but the customers are requests, the stoves are servers, and the chai is data.
2. So What Exactly is System Design?
Here's the one-line definition to remember:
┌─────────────────────────────────────────────────────────────┐ │ │ │ System Design = deciding how the PARTS of a software │ │ system (servers, databases, caches, queues) are arranged │ │ and talk to each other, so it meets its goals under │ │ real-world load. │ │ │ │ It is about TRADE-OFFS, not one "correct" answer. │ │ │ └─────────────────────────────────────────────────────────────┘
In simple words: writing code is deciding what one program does. System design is deciding how many programs, machines, and databases you need — and how they cooperate — so the whole thing is fast, reliable, and doesn't fall over when millions of people show up.
A simple analogy: Coding is being a great chef — you cook one perfect dish. System design is being the restaurant owner — you design the kitchen layout, the waiter flow, the billing counter, and the home-delivery pipeline so 1000 customers get served at once without chaos.
Important — what System Design is NOT:
❌ NOT about memorizing one "right" architecture → it's situational ❌ NOT only for FAANG architects → every backend dev needs it ❌ NOT writing code line-by-line → that's Low-Level Design ❌ NOT magic reserved for 10-yr veterans → it's a learnable skill ✅ IS reasoning about trade-offs out loud, with boxes and arrows
3. Two Altitudes: HLD vs LLD
The phrase "system design" secretly means two different zoom levels. Interviewers mix them up, so you shouldn't.
┌─────────────────────────────────────────────────────────────┐ │ TWO ALTITUDES OF DESIGN │ ├─────────────────────────────────────────────────────────────┤ │ │ │ HLD (High-Level Design) → the CITY MAP 🗺️ │ │ "Which big boxes exist and how do they connect?" │ │ Servers, databases, caches, load balancers, queues. │ │ │ │ LLD (Low-Level Design) → the HOUSE BLUEPRINT 🏠 │ │ "Inside ONE box, what classes/tables/APIs exist?" │ │ Class diagrams, DB schema, function signatures. │ │ │ └─────────────────────────────────────────────────────────────┘
Think of building a city:
HLD = "Put the hospital here, the power plant there,
connect them with these roads." (zoomed OUT)
LLD = "This one hospital has 4 floors, an ICU on floor 2,
and these exact room numbers." (zoomed IN)
This series (Namaste System Design) is mostly about HLD — the big-picture skill that scares people most and shows up in interviews the most. We'll touch LLD where it matters.
4. Why Isn't One Server Enough?
Beginners always ask: "Why not just buy one really powerful computer and run everything on it?" Great question. Let's trace what happens as users grow.
STAGE 1 — THE HAPPY BEGINNING (100 users)
──────────────────────────────────────────
[ Users ] ──HTTP──▶ [ ONE Server + Database ]
Everything on one box. Simple. Works great. 😊
STAGE 2 — IT GETS POPULAR (100,000 users)
──────────────────────────────────────────
[ Users ] ──▶ [ Server ] ← CPU at 100% 🥵
│ ← DB is slow 🐌
▼
[ Database ] ← running out of disk
One box can't keep up. And if it crashes...
EVERYTHING is down. 💀 (a "single point of failure")
STAGE 3 — DESIGN TO THE RESCUE (10,000,000 users)
──────────────────────────────────────────────────
┌──▶ [ Server 1 ]
[ Users ] ─▶ [ LB ]──▶ [ Server 2 ] ──▶ [ Cache ]
└──▶ [ Server 3 ] │
▼
[ Database ]
(+ replicas)
Many servers share the load. One dies? Others cover.
A cache absorbs repeated reads. Now we SCALE. 🚀
So the reason one server isn't enough is two-fold:
1. CAPACITY → one machine has a ceiling (CPU, RAM, disk).
2. FAILURE → one machine = one point of failure. It WILL
crash someday, and then you're 100% down.
System design is the craft of arranging many imperfect machines so that together they are fast and never fully down.
5. The 4 Forces Every System Fights
Every design decision you'll ever make is a tug-of-war between four forces. Memorize these — they are the soul of this whole series.
┌─────────────────────────────────────────────────────────────┐ │ THE 4 FORCES OF SYSTEM DESIGN │ ├─────────────────────────────────────────────────────────────┤ │ │ │ 1. SCALE → Can it handle MORE users/data? (grow) │ │ 2. SPEED → Is it FAST for each user? (latency) │ │ 3. SAFETY → Does it stay UP and not lose data? │ │ (availability + reliability) │ │ 4. COST → Can we AFFORD to run it? ($$$) │ │ │ └─────────────────────────────────────────────────────────────┘
Here's the catch that makes design an art: you usually can't max out all four. Pushing one often hurts another.
Want more SPEED? → add caches/servers → COST goes up 💸 Want more SAFETY? → add backup copies → SPEED can drop 🐢 Want less COST? → fewer machines → SCALE suffers 📉
This is why there's no single "correct" answer. A good designer says: "For a banking app I'll pay more for safety; for a meme site I'll trade some safety for low cost." Same problem, different priorities, different design.
6. Functional vs Non-Functional Requirements
Before designing anything, you split the problem into two buckets. This is the very first move in every interview.
| Functional Requirements | Non-Functional Requirements | |
|---|---|---|
| Question it answers | WHAT does it do? | HOW WELL does it do it? |
| Example (WhatsApp) | "User can send a message" | "Message arrives in < 1 second" |
| Example (YouTube) | "User can upload a video" | "Video plays without buffering for 1M viewers" |
| Feels like | Features / verbs | Qualities / the "-ilities" |
| Who cares most | Product manager | System designer (you!) |
Key insight: anyone can list features. The hard, interesting, interview-worthy part is the non-functional stuff — scalability, availability, latency, consistency. That's where system design actually lives.
7. Let's Trace a Real Decision By Hand
Let's design one tiny thing — "a Like button on a photo" — and watch the trade-offs appear. This is exactly how real design thinking feels.
PROBLEM: A photo gets 1,000,000 likes/second (viral post).
──────────────────────────────────────────────────────────
Naive idea:
Every like ──▶ UPDATE photos SET likes = likes + 1
...on the database, instantly.
What breaks?
1,000,000 writes/sec to ONE row → database melts. 🔥
Designer's move #1 (trade SPEED of freshness for SCALE):
Count likes in a fast in-memory CACHE.
Save to the database once every few seconds (batch).
Result: DB gets ~1 write/sec instead of 1,000,000. ✅
Cost: the like count might be a few seconds stale. 🤔
Ask the real question:
"Does a user care if the count says 2,300,101 vs
2,300,140 for two seconds?" → Nope!
So we HAPPILY trade perfect freshness for massive scale.
See what happened? We didn't write much code. We identified the bottleneck, proposed a trade-off, and justified it with the real-world need. That instinct — "what breaks, and what can I trade?" — is the entire skill. Everything else in this series is just vocabulary to make these trades.
8. How to Think Like a Designer (Not Just a Coder)
CODER MINDSET 👨💻 DESIGNER MINDSET 🧠
───────────────── ──────────────────
"How do I write this "What happens when 10 million
function correctly?" people call this at once?"
"Does it work?" "Does it still work when a
server dies at 3am?"
"Which library?" "Which trade-off?
Speed vs cost vs safety?"
"One machine, my laptop." "Many machines, some WILL fail."
You don't throw away the coder brain — you add the designer brain on top. The designer always assumes: traffic will spike, machines will crash, networks will lag, and money is finite. Design for that reality and you'll never be caught off guard.
9. Little Traps Beginners Fall Into
┌─────────────────────────────────────────────────────────────┐ │ COMMON MISCONCEPTIONS ❌ │ ├─────────────────────────────────────────────────────────────┤ │ │ │ "There's one correct architecture to memorize." │ │ → No. It always depends on requirements & trade-offs. │ │ │ │ "I should jump straight to drawing databases." │ │ → No. First clarify requirements & estimate scale. │ │ │ │ "Bigger/more servers always fixes it." │ │ → Often the bottleneck is the database or a bad design. │ │ │ │ "More features = better design." │ │ → In interviews, depth on trade-offs beats breadth. │ │ │ │ "It's only useful for interviews." │ │ → It's how every real product survives growth. │ │ │ └─────────────────────────────────────────────────────────────┘
Interview Questions — Quick Fire!
Q: What is system design in one sentence?
"System design is the process of defining the architecture, components, and data flow of a software system so that it meets its functional and non-functional requirements — like scalability, availability, and low latency — at real-world scale. It's fundamentally about making and justifying trade-offs."
Q: What's the difference between HLD and LLD?
"High-Level Design is the big-picture architecture — the major components like servers, databases, caches, and load balancers, and how they connect. Low-Level Design zooms into a single component — its classes, database schema, and API contracts. HLD is the city map; LLD is the blueprint of one building."
Q: Why can't we just run everything on one powerful server?
"Two reasons. First, capacity — a single machine has a hard ceiling on CPU, RAM, and disk, so it can't grow forever. Second, reliability — one server is a single point of failure; if it crashes, the whole system is down. Distributing across many machines lets us scale beyond one box and stay available even when individual machines fail."
Q: What are functional vs non-functional requirements?
"Functional requirements describe WHAT the system does — the features, like 'a user can post a photo.' Non-functional requirements describe HOW WELL it does them — qualities like latency, scalability, availability, and consistency, for example 'the photo loads in under 200 milliseconds for 10 million users.' System design mostly focuses on the non-functional side."
Q: Is there always one correct answer in system design?
"No — and that's the whole point. Every design is a trade-off between scale, speed, safety, and cost. The 'best' design depends on the requirements: a banking system prioritizes consistency and safety, while a social media feed might trade perfect consistency for speed and availability. A strong answer explicitly states its assumptions and justifies each trade-off."
Key Points to Remember
| Concept | Key Takeaway |
|---|---|
| What is it | Arranging system parts to meet goals at scale — it's about trade-offs. |
| HLD vs LLD | HLD = city map (big boxes) · LLD = building blueprint (inside one box). |
| Why not one server | Capacity has a ceiling + one box is a single point of failure. |
| The 4 forces | Scale · Speed · Safety · Cost — you can't max all four at once. |
| Requirements | Functional (WHAT) vs Non-functional (HOW WELL). Design lives in the latter. |
| Core skill | "What breaks, and what can I trade to fix it?" |
What's Next?
In Chapter 02, we tackle the very first tool in every designer's belt: scaling. You'll learn the two ways to grow a system — vertical (a bigger machine) vs horizontal (more machines) — why the entire internet runs on the horizontal kind, and the one magic word (stateless) that makes it all possible. We'll go back to Sharma Ji's chai stall to make it stick.
Keep designing, keep scaling! See you in the next one!
Post a Comment