Advanced System Design Interview Masterclass
Clarification and Ambiguity
The First Five Minutes
The most critical part of a system design interview happens before you draw a single box. An ambiguous prompt like “Design a ride-sharing service” isn't an invitation to immediately start listing components. It’s a test of your ability to define the problem you're actually solving. Your first job is to transform that ambiguity into a concrete set of technical challenges.
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions, clarify ambiguities, and define the system's scope more precisely.
Jumping into a solution without this clarity is a common mistake. You risk designing a system for the wrong problem, or a problem so large it's impossible to cover in 45 minutes. The goal is to collaborate with the interviewer to establish a shared understanding of the system's boundaries and goals.
Beyond Features to Constraints
At a senior level, functional requirements are just the starting point. Anyone can list features like "user books a ride" or "driver accepts a trip." The real engineering challenge lies in the non-functional requirements that emerge at scale. These are the constraints that shape every architectural decision you'll make.
Your clarifying questions should push past the what and into the how many, how fast, and how reliable.
| Vague Prompt | Clarifying Questions to Ask |
|---|---|
| Design a photo-sharing app. | What's the expected number of daily active users (DAU)? How many photo uploads per second should we support at peak? What's the p99 latency target for loading a user's feed? |
| Design a URL shortener. | How many new URLs will be shortened per month? Are the links permanent, or do they expire? What is the availability target? Can the redirect service ever go down? |
| Design a real-time stock ticker. | How many symbols do we need to track concurrently? What is the maximum acceptable delay between a market event and a user seeing the update? Are there data residency requirements for financial information? |
These questions help you quantify the problem. An answer like "we need to handle 100,000 requests per second with less than 200ms p99 latency" is far more useful than "it needs to be fast."
Finding the Crux
Every system has a 'hard part'—a central technical challenge that dictates the architecture. For a ride-sharing app, it might be the real-time geolocation matching system. For a log analytics platform, it could be the high-throughput data ingestion and indexing pipeline. Your initial questions should help you zero in on this crux.
Is the system read-heavy or write-heavy? Does it require strict consistency or is eventual consistency acceptable? Are there traffic bursts we need to handle? Identifying this bottleneck early allows you to focus your time on the most interesting and difficult aspect of the design.
This discovery process culminates in defining clear service-level objectives (SLOs). These are specific, measurable targets for your system's performance.
SLO
noun
A Service-Level Objective is a target value or range of values for a service level that is measured by a service-level indicator (SLI). It is a key element of a Service-Level Agreement (SLA) between a service provider and a customer.
Common SLOs revolve around availability, latency, and throughput. For example, you might state: "The system will have 99.9% availability. The p99 latency for the ride-matching API will be under 200ms. The system will support a peak throughput of 100,000 requests per second."
Control the Scope
Finally, a critical skill is actively managing the scope of the interview. You cannot design all of Uber in an hour. It's not expected.
Explicitly state what you will not be designing. This shows focus and an understanding of how to manage complex projects. You can park non-critical features to address later if time permits.
For this design, I'll focus on the core ride-booking and driver-matching flow. I'll consider features like payments, user profiles, and surge pricing to be out of scope for our initial discussion.
This approach demonstrates maturity. It transforms the interview from a frantic race to cover everything into a focused technical discussion on a well-defined problem. By nailing the clarification phase, you set the stage for a successful design.
Ready to test your understanding of these principles?
When presented with an ambiguous prompt like “Design a photo-sharing service,” what is the most effective first step?
Which of the following is a well-defined Service-Level Objective (SLO)?
Mastering this initial phase of requirements gathering is what separates a good design from a great one. It frames the entire conversation and showcases your ability to handle complexity and ambiguity.