How to Think Like a System Designer
You'll learn to
- -Distinguish functional from non-functional requirements
- -Know why every design starts with a rough estimate, not a diagram
- -Have a repeatable first move for any design problem
Before you place a single box on a canvas, a system designer answers two questions: "what does this system need to do?" and "how much of it, how fast, for how many people?" Skipping either question is the single most common reason a design falls apart, whether under interview scrutiny or real production traffic.
Functional vs. Non-Functional Requirements
Functional requirements are the verbs: "users can post a photo," "the system sends a notification within 5 seconds," "an admin can ban a user." They describe behavior. Non-functional requirements are the constraints those behaviors must survive: how many users, how many requests per second, what latency is acceptable, what happens during a traffic spike, what happens when a server dies. A design that nails the functional requirements but ignores the non-functional ones is a prototype, not a system.
- -Functional describes what the system does: features, user flows, business rules.
- -Non-functional describes how well it does it: scale, latency, availability, consistency, cost.
- -Non-functional requirements are what turn "a working demo" into "a system that survives Black Friday."
Why Estimate Before You Design
A system serving 1,000 users and a system serving 100 million users are not the same system with more servers bolted on; they are architecturally different. A single PostgreSQL instance is the right answer at the first scale and actively wrong at the second. That is why every serious design starts with rough, order-of-magnitude estimation: how many users, how many requests per second, how much data, growing at what rate. You do not need precision. You need to know whether you are building for a thousand users or a billion, because that decides everything downstream.
Fast, rough calculations to size your system. Used in system design interviews to justify technology choices.
A civil engineer doesn't design the Golden Gate Bridge before estimating "hmm, ~100,000 cars per day, each weighing ~2 tons, so load = ~200M kg/day". These rough numbers drive the design. You do the same for software systems.
Before designing ANY system, estimate: (1) How much data? (2) How many QPS (queries per second)? (3) What is the acceptable latency?
Key Units: 1 million = 10^6, 1 billion = 10^9. Power of 2: 1KB=10^3, 1MB=10^6, 1GB=10^9, 1TB=10^12. Always round aggressively to enable mental math.
Estimation Example - Twitter Feed: 300M daily users, 50% post per day = 150M tweets/day = ~1,750 tweets/second. Average tweet = 140 chars + metadata ≈ 500 bytes. Storage per day = 1750/s × 500B × 86400s ≈ 75GB/day. In 5 years ≈ 140TB. This tells you: need distributed storage, need partitioning by tweet_id.
Traffic estimation: Daily active users (DAU) × actions per day / 86,400 seconds = QPS. For peak: multiply by 2-3x (reads often 100x writes). Example: 10M DAU - 10 reads/day / 86400 ≈ 1,157 QPS average, 3,500 peak.
Storage estimation: Data size - users - retention period. Example: Instagram - 100M users upload 1 photo/week, average 2MB per photo. Per week: 100M × 2MB = 200TB. Per year: 10PB. This drives: object storage (S3), CDN (CloudFront), image compression pipeline.
- -In interviews, never skip estimation - it justifies every technology choice you make.
- -QPS under 100: single server. 100-1000: single optimized server. 1000+: horizontal scaling needed.
- -Storage under 1TB: single server/managed DB. 1TB-10TB: managed cluster. 10TB+: distributed storage.
- -Always ask: read-heavy or write-heavy? 80:20 read:write is typical social media.
- -Cache ratio: if 80% of traffic is to 20% of data, caching has a massive ROI.
A Repeatable First Move
When you are handed a vague prompt - "design a notification system" - resist the urge to start drawing boxes immediately. Instead, work through this sequence, which every chapter in this course implicitly follows:
- -1. Clarify functional scope: what must it do, and just as importantly, what is explicitly out of scope?
- -2. Estimate scale: users, QPS, data volume, growth rate.
- -3. Sketch the high-level flow - client to server to storage, in the simplest shape that could work.
- -4. Identify the bottleneck: which single piece will break first as scale grows?
- -5. Discuss the trade-off: what did you sacrifice (cost, consistency, complexity) to fix that bottleneck?
This 5-step loop is exactly what you will practice, piece by piece, for the rest of the course, and it is exactly what the HLD Lab's missions and scoring are checking for.
"Design a URL shortener." What's the first thing you say?
"Okay, I'll hash the long URL to generate a short code, store it in a database, and redirect on lookup." Technically not wrong, but it answers a question nobody asked yet, and it's the same answer whether this system serves 100 users or 100 million.
"Before I design anything - are we talking a few thousand links a day, or Bit.ly scale? Is a link permanent, or does it expire? Do we need click analytics?" Only after those answers does a concrete design get proposed, and it looks different depending on the answers.
Which of these is a non-functional requirement?