Learn System Design with System building, Subscribe Hands On coding course - LogStream
There’s a version of the system design interview where the candidate designs Twitter. The entire Twitter. Timeline, search, notifications, recommendations, ads, analytics, direct messages.
At the 40-minute mark they’re still drawing boxes. They haven’t gone deep on anything. The interviewer writes “breadth over depth, no clear prioritization” on the scorecard.
This is the most common failure mode among technically strong candidates, and it has nothing to do with technical knowledge. It’s a scoping problem.
Here’s the discipline that fixes it.
The negotiation in the first five minutes
Most candidates use the first five minutes to ask clarifying questions. How many users? What’s the read:write ratio? Does this need global availability?
These are fine questions. They’re also generic — they could be asked for any question. They don’t signal to the interviewer that you understand how to manage scope.
The candidates who score well on problem scoping don’t just ask questions. They propose scope.
“There are several interesting subsystems here: the timeline, search, notifications, the recommendation algorithm, and the ad serving layer. I’m going to focus on the timeline and the fan-out architecture. I’ll acknowledge the others exist and sketch where they’d connect, but I won’t design them in detail. Does that direction work for you?”
This is different from asking questions. You’re proposing what you’re going to design and explicitly not design, and you’re inviting the interviewer to redirect if they want something different.
Most interviewers will say yes. Some will redirect you: “Actually, I’m more interested in the fan-out problem for group chats specifically.” This is useful information you would not have gotten without proposing scope first.
Why the pressure to cover everything exists
The instinct to design everything is understandable. The interview is evaluating your technical breadth, right? If you only design one component, won’t the interviewer think you don’t know the rest?
This misunderstands what the interview is evaluating.
Interviewers at L5+ levels are not checking whether you’ve memorized the architecture for every subsystem of Twitter. They know you’re familiar with notifications and search — you work as a software engineer. What they can’t infer from your resume is whether you can identify the hardest distributed systems problem in a question, scope down to it, and go deep enough to demonstrate real understanding.
Designing eight systems shallowly proves you’re familiar with eight systems. Designing one system deeply proves you can think through the hard parts of a complex problem. The second is what they’re scoring.
How to choose what to scope in
The right component to go deep on is the component with the most interesting distributed systems problem. Not the component you know best. Not the component that feels safest. The component where the answer is genuinely non-obvious.
For Twitter: the fan-out problem is more interesting than the user profile service. The timeline cache architecture is more interesting than the follow/unfollow API. Go where the hard problem lives.
A useful test: which component, if I described it at a surface level, would the interviewer immediately probe deeper on? That’s the component to start with.
What to do with the components you’re not designing
You don’t ignore them. You acknowledge them.
“Notifications would follow a standard fan-out-on-write pattern with push to APNs/FCM for mobile and WebSocket for web, similar to what we discussed for the timeline. I’m not going to design it in detail, but the interesting problem there is the delivery guarantee under failure — we’d need at-least-once delivery with client-side dedup.”
One sentence that shows you understand the problem, the standard solution, and the interesting edge case — without spending five minutes on a full design. This signals breadth without consuming depth time.
The specific framing that works
After the estimation section, before drawing anything, say this out loud:
“Before I draw the architecture, I want to lock scope. I’m going to go deep on [component X] because that’s where the interesting distributed systems problem is. I’ll acknowledge [components Y and Z] exist and show where they connect, but I won’t design them fully unless you’d like me to. Does that work?”
The explicit scope lock serves two purposes. It sets expectations so the interviewer isn’t waiting for you to cover components you’ve already decided to skip. And it gives the interviewer one last opportunity to redirect before you’ve committed 30 minutes to the wrong area.
After this moment, the scope is locked. Don’t drift. If you finish the deep dive early, go deeper on the component you chose — don’t add new components to fill time.
The uncomfortable truth about breadth
Demonstrating breadth is valuable. Demonstrating it through shallow coverage of many components is not the right way.
The right way: show breadth through the quality of your acknowledgments. When you mention a component you’re not designing and you correctly name the problem it has and the standard approach for solving it, you’ve shown breadth in one sentence. Compare that to spending five minutes on a shallow design of the same component — same signal, five minutes cheaper.
Scope discipline isn’t about knowing less. It’s about deploying what you know efficiently enough to demonstrate depth where it matters.
CTA: Tuesday’s paid post is the full WhatsApp walkthrough — including how to scope it correctly when the question says “design a messaging system” and you have 50 minutes.
Subscription link
https://systemdr.systemdrd.com/subscribe
—Sumedh
The Question Vault has all 52 walkthroughs organized by archetype — so you can see the pattern across questions, not just the surface answer.
Access all 52 Quesstions here
Curious how this works in real systems?
The paid lessons cover scalability, optimization, and real-world engineering patterns.