Scoping the System: Taming the open-ended prompt
Navigating the transition from solving isolated algorithmic puzzles to architecting a complete application is the most significant hurdle for any developer in the interview loop. The System Design round is notoriously intimidating because the prompts are deliberately vague. An interviewer will simply say, “Design Twitter,” and hand you a marker.
The fastest way to fail this round is to immediately start drawing databases and load balancers. A common failure point in system design is not a lack of architectural knowledge, but a lack of defined boundaries. Without a rigorous scope, your whiteboard design will suffer from feature creep, where the constant addition of new ideas makes it impossible to finish the architecture in the allotted 45 minutes.
Scoping is the professional process of deciding exactly what the application will do, and, more importantly, what it will not do, before the first box is drawn.
The Minimum Viable Product (MVP) framework
In a professional engineering interview, you must aim for the Minimum Viable Product. This is the most stripped-down version of the system that still solves the core problem for the user.
When handed a massive prompt like “Design Twitter,” you must actively collaborate with the interviewer to separate the system into distinct buckets:
- Non-Negotiables: Features that the app cannot function without. For Twitter, this is user registration, publishing a text-based tweet, and viewing a timeline of followed users.
- Enhancements: Features that improve the experience but aren’t vital for the initial design. For Twitter, this might be replying to tweets or liking them.
- Out of Scope (Future Iterations): Complex features that require significant research or infrastructure. You must explicitly tell the interviewer: “For this 45-minute session, we will consider video processing, trending topic algorithms, and push notifications out of scope”.
Capacity Estimation (The Scale Constraints)
Before evaluating different system design patterns to ensure your project’s infrastructure matches its intended scale, you must ask the interviewer for the system’s constraints. You cannot design a system without knowing the load it must bear.
- Traffic Volume: Ask for the expected Daily Active Users (DAU). Designing a system for 10,000 users requires a fundamentally different architecture than designing for 100 million.
- Read-to-Write Ratio: Is the system read-heavy (like Twitter, where millions read a tweet but only one person wrote it) or write-heavy (like a metrics logging system)? This ratio dictates your database selection and caching strategy.
- Data Metrics: Estimate the size of the payload. If users can only upload 140 characters of text, the storage requirements are minimal. If they can upload 4K video, you immediately need robust cloud object storage.
Defining the Data Model Requirements
Once the features and scale are agreed upon, scoping moves to the bottom of the stack. You cannot design an API or a data flow if you do not know the shape of the data.
During the scoping phase, you should list every primary entity in your system and their relationships. Write these clearly on the side of the whiteboard so they act as your “Source of Truth” document, keeping you focused when the complexity of the full-stack environment begins to mount.
/**
* Example of a System Scope Contract during an interview.
* Writing this on the whiteboard establishes mutual agreement
* with the interviewer before you begin drawing infrastructure.
*/
const systemScope = {
systemName: "Twitter (MVP)",
scale: "100M DAU, Highly Read-Heavy (100:1 Read/Write Ratio)",
requirements: {
inScope: [
"Users can publish text-based tweets",
"Users can follow other users",
"Users can view a chronological timeline of followed tweets"
],
outOfScope: [
"Media uploads (Images/Video)",
"Retweets and threaded replies",
"Machine learning timeline recommendations"
]
},
coreEntities: [
"User (ID, Username, Email, CreatedAt)",
"Tweet (ID, AuthorID, Content, Timestamp)",
"Follow (FollowerID, FolloweeID, Timestamp)"
]
};
Learning Point: Interviewers leave prompts vague on purpose to test your communication. If you design a system that handles 10 million video uploads a second, but the interviewer only wanted a text-based MVP, you have failed the communication test. Always establish a clear “Definition of Done” for the interview session to ensure you don’t get stuck in unnecessary complexity.
Popular Guides