Your friend asks you to "design an app to split expenses with roommates." Before you draw a single box, stop — what does that even mean? Splitwise-style, with settle-up suggestions? Just three of you, or does it need to handle a large hostel wing? Once a day, or constantly, live, as people add expenses mid-conversation? Every one of those answers changes the design. This lesson is about forcing those answers out into the open before you design anything.
Functional vs non-functional requirements
Functional requirements are the actual features: a user can add an expense, split it among roommates, and see who owes whom. Simple to list, and most candidates get these right without help.
Non-functional requirements are everything about HOW WELL those features need to work — how many users, how fast must a response come back, how available must it be, is losing a rare write acceptable. These are the requirements that actually decide your architecture, and they are the ones candidates most often skip. "Split an expense" needs almost no design thought by itself; "split an expense, for 50 million users, updating in under 200ms" needs an entire architecture.
Clarifying questions that actually change the design
Not every clarifying question is worth asking — "what programming language should I use?" wastes precious minutes. The questions worth asking are the ones whose answer would send you down a genuinely different path:
- Read-heavy or write-heavy? A URL shortener is read-heavy (one shorten, millions of redirects) — that argues for caching. A logging system is write-heavy — that argues for a write-optimized store and batching.
- Strong or eventual consistency? A bank balance needs strong consistency. A like count can lag by a second with zero real consequence.
- Roughly what scale? Even a rough answer ("think Instagram-scale, not a 50-person office tool") changes whether sharding is a real consideration at all.
Back-of-the-envelope maths
Capacity estimation is not precise computation — it is fast reasoning with round numbers, in orders of magnitude. The recipe: start from a stated or reasonably assumed total (daily active users, or total records), convert to a per-second rate by dividing by roughly 86,400 seconds in a day (round to 100,000 for fast mental math), and separately estimate storage per record multiplied by total records.
A worked example: the roommate expense app
Say your friend clarifies: 10,000 households use the app, each household logs roughly 5 expenses a day, and each expense record is about 200 bytes (amount, description, who paid, who owes).
Writes/day = 10,000 households × 5 expenses = 50,000 writes/day Writes/sec ≈ 50,000 / 86,400 ≈ 0.6 writes/sec (tiny!) Storage/day = 50,000 × 200 bytes ≈ 10 MB/day Storage/yr ≈ 10 MB × 365 ≈ 3.65 GB/year
Notice the conclusion: this system is nowhere near a scale that needs sharding, a message queue, or aggressive caching — a single well-chosen database comfortably handles it for years. Saying that OUT LOUD, backed by the maths, is a stronger answer than silently over-engineering because the word "app" sounded like it needed one.
Common mistakes
- Skipping estimation entirely and designing from a gut feeling about scale.
- Spending too long on precise math instead of fast, rounded estimates.
- Asking clarifying questions that don't actually change the design (bikeshedding).
- Forgetting to also estimate bandwidth (requests × average response size) when large payloads are involved.
- Never revisiting the estimate after the interviewer adds a new requirement mid-interview.
Quick recap
| Concept | One-liner |
|---|---|
| Functional reqs | What the system does. |
| Non-functional reqs | How well — scale, speed, consistency — and what actually shapes the architecture. |
| Good clarifying questions | Ones whose answer sends you down a genuinely different path. |
| Estimation | Round numbers, orders of magnitude, fast — not precision. |
Practice Zone
Five MCQs, then two applied questions.
Why do interviewers want you to ask clarifying questions before designing?
Asked in
10 million daily active users each make 20 requests/day. What is the approximate AVERAGE requests-per-second (QPS)?
Asked in
Why do system designers apply a 'peak multiplier' (e.g. 5x) on top of average QPS?
Asked in
You calculate ~11,500 peak QPS with a 90:10 read:write ratio. What should this number change in your design?
Asked in
Which of these is a NON-functional requirement?
Asked in
50 million daily active users send an average of 40 messages/day, each message averaging 100 bytes. Estimate the daily storage need (ignore metadata/overhead for now), and say in one line why this number matters.
Asked in
The prompt is 'Design a ticket booking system' (think BookMyShow/IRCTC-style). Write 4 clarifying questions whose answers would genuinely change your architecture.
Asked in
FAQ
How long should capacity estimation take in a real interview?
Roughly 5 minutes out of a 45-minute round — enough to establish rough QPS and storage, not to compute exact figures.
What if I don't know a realistic number to assume (like average file size)?
Say a reasonable assumption out loud ("let's assume an average photo is 2MB") and move on — interviewers care that you reason with SOME number, not that you know the exact real-world figure.
Is skipping this step ever OK?
Only for a genuinely tiny, clearly-scoped system where the interviewer explicitly says scale isn't the focus — otherwise, skipping it is one of the most common reasons a strong coder still does poorly in HLD rounds.
Next: Lesson 3 — Latency, Throughput, Availability & Reliability →