Courses

System DesignHigh-level system design, one everyday scene at a time: 30 concepts and 15 interview rounds.712 lessons

All courses Tutorials My Learning

Categories

Read & write

All storiesEvery post, newest first.Write for usPublish your stories and earn from what you write.Writer leaderboardsWho is writing the most read posts.

Categories

Featured

JSON FormatterFormat, validate and minify JSON.Regex TesterTest patterns against live text.Merge PDFCombine PDFs in your browser.JWT DecoderRead a token’s header and claims.Password GeneratorStrong passwords, generated locally.Gradient GeneratorBuild CSS gradients visually.

Play a round

DevdleOne developer word a day, six guesses.Python RushClassic snake, with coding icons to eat.Blink or BreakA quick test of your reflexes.

Learn with us

Live CoursesInstructor-led courses. Join a waitlist and be first in when one starts.LearningStructured programming courses with AI assistance and certificates.

System Design

1. How to Approach a Design Question

Lesson 18 of 21

1. How to Approach a Design Question

1. How to Approach a Design Question

Interview questions

8 min read+10 XP

Interview questions (with the counter-questions you'll get)

These questions come up in nearly every design round, whatever the system. For each: what they're really testing, a strong answer, the counter-questions they're likely to throw back, and the trap to avoid.

Q1. "Design X." (The opening.) What do you do in the first two minutes?

They're testing: whether you clarify before solving.

Think about your answer first, then open it.

reveal

Q2. What are the functional and non-functional requirements here?

They're testing: whether you know the difference and can prioritise.

Think about your answer first, then open it.

reveal

Q3. "How much traffic should we expect? You tell me."

They're testing: whether you can turn vague scale into numbers.

Think about your answer first, then open it.

reveal

Q4. Why did you choose this database?

They're testing: whether choices come from requirements, not habit.

Think about your answer first, then open it.

reveal

Q5. What's the bottleneck in your design?

They're testing: whether you can find the weak point yourself.

Think about your answer first, then open it.

reveal

Q6. What happens if this component fails?

They're testing: whether you design for failure.

Think about your answer first, then open it.

reveal

Q7. How would this change at 10 times or 100 times the scale?

They're testing: whether you know which parts break first and why.

Think about your answer first, then open it.

reveal

Q8. What are the trade-offs in your design?

They're testing: honesty about costs.

Think about your answer first, then open it.

reveal

Q9. What would you do with more time?

They're testing: whether you know where your design is thin.

Think about your answer first, then open it.

reveal

Q10. "Have you used X?" when you haven't.

They're testing: honesty and reasoning from first principles.

Think about your answer first, then open it.

reveal

Q11. "Why not just use microservices / Kafka / [popular tool]?"

They're testing: whether you can resist over-engineering.

Think about your answer first, then open it.

reveal

No tracks available

Lofi Player

1Show the strong answer, counter-questions and trap
2**Strong answer:** Don't draw yet. Restate the problem in one line, then ask SCALE questions: which features are in scope, how many users and how much data, read-heavy or write-heavy, latency and uptime needs, and how exact the data must be. Write the agreed requirements down, then move to estimates.
3
4**Counter-questions:**
5- *"Just assume whatever you like."* → State your assumptions out loud and write them down: "I'll assume 100 million new links a month and 100 reads per write." Assumptions you can defend are fine. Silent ones aren't.
6- *"Why are you asking so many questions?"* → Because the numbers and priorities change the design. A shortener for one company's internal links and one for the whole internet are different systems.
7
8**Trap:** drawing boxes in the first minute.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Functional requirements are what the system does (shorten a URL, redirect a code). Non-functional requirements are how well it does it (low latency, high availability, durability, scale). Then name the one or two non-functional requirements that matter most for this system. For a shortener, that's fast, highly available redirects, because a broken link is visible to everyone.
3
4**Counter-questions:**
5- *"Which matters more here, consistency or availability?"* → For redirects, availability: a link that works slightly late is fine, a link that fails isn't. For creating a link, the code must be unique, so that part needs a correct, consistent write.
6- *"What's out of scope?"* → Say it explicitly: "I'll leave out user accounts and custom domains unless you want them."
7
8**Trap:** listing only features and forgetting the qualities.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Pick a sensible assumption, say it out loud, and turn it into per-second numbers. "Say 100 million new links a month. A month is about 2.6 million seconds, so that's roughly 40 writes a second. At 100 reads per write, about 4,000 redirects a second on average, more at peak." (Chapter 2 covers this in depth.)
3
4**Counter-questions:**
5- *"What about peak traffic?"* → Peaks are often several times the average. Design for the peak, not the average. I'd assume 2 to 3 times the average unless we know more.
6- *"Does 4,000 a second need many servers?"* → Not necessarily. Many single servers can handle that for simple lookups, but we still want more than one for availability, and a cache keeps it cheap.
7
8**Trap:** refusing to pick a number, or picking one and never using it.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Tie it to the access pattern. "Every lookup is by exact code, there are no joins, and we'll store billions of rows. A key-value store fits that access pattern and scales out easily. A relational database with the code as primary key would also work at moderate scale. I'd pick based on what the team already runs well."
3
4**Counter-questions:**
5- *"Why not just Postgres?"* → It's a valid choice. The question is whether one instance handles our storage and read load. With caching and read replicas it can go a long way. Sharding comes in when one machine can't hold the data.
6- *"What would make you change your mind?"* → If we needed complex queries across links (analytics by user, by date), a relational model or a separate analytics store would fit better.
7
8**Trap:** "because it scales" with no link to the requirements.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Follow the heaviest traffic. For a shortener, redirects outnumber writes about 100 to 1, so the read path to storage is the likely bottleneck. That's why a cache sits in front of the database. The next one is the ID maker on the write path, if it's a single server.
3
4**Counter-questions:**
5- *"And after you add the cache?"* → Then it's hot keys (one viral link hammering one cache node) and the database on cache misses. Fixes include replicas for hot keys and a CDN for the most popular redirects.
6- *"How would you know in production?"* → Watch latency percentiles and saturation per component, and look at where queues build up (Chapter 30).
7
8**Trap:** "there's no bottleneck".

1Show the strong answer, counter-questions and trap
2**Strong answer:** Go box by box. App servers are stateless, so the load balancer routes around a dead one. If the cache dies, we fall back to the database, which slows down but keeps working, so the database needs headroom and limits. If the database leader dies, a replica takes over. The ID maker must not be a single point of failure, so we'd run more than one with separate ID ranges.
3
4**Counter-questions:**
5- *"What if a whole data centre goes down?"* → Replicate to a second region and route traffic there with DNS or global load balancing. The cost is higher spend and harder consistency.
6- *"What if the load balancer itself fails?"* → Run load balancers in a redundant pair, or use a managed one that's already redundant.
7
8**Trap:** answering "it won't fail".

1Show the strong answer, counter-questions and trap
2**Strong answer:** Redo the numbers, then check each component against them. At 10 times, more app servers and a bigger cache usually do it. At 100 times, the database may no longer fit on one machine, so we shard by code, and the ID maker needs to hand out ranges so it isn't a bottleneck.
3
4**Counter-questions:**
5- *"What's the first thing to break?"* → Usually storage: the database's write capacity or disk size, since app servers scale out easily.
6- *"Would you redesign from scratch?"* → No. A good design grows by adding pieces (cache, replicas, shards), not by starting over.
7
8**Trap:** jumping to "use microservices" as the scaling answer.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Name two or three big ones in "because, cost, unless" form. For example: a 302 redirect for analytics, at the cost of more server traffic; caching for speed, at the cost of rare stale data after edits; a counter-based ID for guaranteed uniqueness, at the cost of guessable codes.
3
4**Counter-questions:**
5- *"How would you fix the guessable codes?"* → Shuffle or encrypt the counter value before encoding it, or use random codes with a uniqueness check on write.
6- *"Which trade-off would you revisit first?"* → Whichever one the requirements care about most. If privacy matters, the guessable codes.
7
8**Trap:** "my design has no downsides".

1Show the strong answer, counter-questions and trap
2**Strong answer:** Name the parts you skipped or simplified and what you'd add. "Rate limiting so nobody can create millions of links, abuse detection for malicious URLs, analytics as a separate pipeline, multi-region for disaster recovery, and monitoring with alerts on redirect latency."
3
4**Counter-questions:**
5- *"Which one first?"* → Rate limiting and abuse checks, because a shortener is a common tool for spam, and that hurts every user.
6
7**Trap:** "nothing, it's complete".

1Show the strong answer, counter-questions and trap
2**Strong answer:** Say no plainly, then reason. "I haven't used it in production. From what I know, it's a ___, so I'd expect it to be good at ___ and weak at ___. For this design, the property I need is ___, so here's how I'd check it fits."
3
4**Counter-questions:**
5- *"Then what would you use instead?"* → Name something you do know that gives the same property, and explain the property, not the brand.
6
7**Trap:** bluffing details you don't know. Interviewers often probe until a bluff breaks.

1Show the strong answer, counter-questions and trap
2**Strong answer:** Every tool solves a specific problem and adds cost. Use it when the problem exists. "At 40 writes a second, a queue between services adds latency and moving parts for no gain. If we add heavy analytics processing later, a queue for click events would make sense, because it separates the slow work from the redirect path."
3
4**Counter-questions:**
5- *"But big companies use microservices."* → They do, mostly to let many teams work independently at huge scale. That's an organisational problem as much as a technical one. For one team and this load, a well-structured single service is simpler to run (Chapter 27).
6
7**Trap:** agreeing just because the tool is popular.
8
9---
10
11## Practice coverage
12
13Every sub-topic in this chapter is tested at least once.
14
15| Sub-topic | Tested by |
16|---|---|
17| 1.1 What the interview is | Q1, Q10 |
18| 1.2 What's scored | Level 4B, Q5, Q8 |
19| 1.3 The framework | Level 5 |
20| 1.4 Timing | Level 4B |
21| 1.5 Clarifying questions (SCALE) | Level 1B, Level 5.1, Q1 |
22| 1.6 Functional vs non-functional | Level 1A, Level 5.1, Q2 |
23| 1.7 API | Level 3, Level 5.3 |
24| 1.8 Data model | Level 5.4, Q4 |
25| 1.9 High-level design | Level 5.5, Q6, Q7 |
26| 1.10 Deep dive | Level 4A, Level 5.6, Q5 |
27| 1.11 Trade-offs | Level 5.7, Q8, Q11 |
28| 1.12 When stuck | Level 4B, Q10 |
29| 1.13 Common mistakes | Level 4B, Q11 |
30| 1.14 The bar | Q6, Q7, Q9 |
31| Estimates (preview of Ch 2) | Level 2, Q3 |
32
33---