A system design interview isn't a test of memorization. It's a collaborative problem-solving session. The interviewer gives you a vague prompt, like "Design a Twitter feed," and watches how you navigate the ambiguity. Your goal isn't to produce a single perfect answer, but to demonstrate a structured thought process. We can break this process down into four distinct steps.

This framework helps you manage the 45-60 minute interview, ensuring you cover all critical aspects of the design. The steps are:

1. Scope the Problem: Clarify requirements and constraints.
2. High-Level Design: Sketch the main components and data flow.
3. Deep Dive: Zoom in on specific components to discuss trade-offs.
4. Wrap Up: Identify bottlenecks and suggest future improvements.

Never start designing immediately. The initial prompt is intentionally vague to test your ability to gather information. Your first task is to ask clarifying questions and establish the system's boundaries. You'll define two types of requirements: functional and non-functional.

Once requirements are clear, you must estimate the scale. This is where back-of-the-envelope calculations come in. These rough estimates guide your architectural choices. For example, if you're designing a service with 100 million daily active users (DAU), a single database server won't be enough. Your math proves it.

Let's estimate the write throughput for our Twitter-like service. Assume we have 300 million DAU, and 10% of them post one tweet per day.

This calculation is a simplified average. A real-world system experiences peaks. You might mention that peak traffic could be 2-3x the average, so you should design for around 1,000 QPS. This shows the interviewer you're thinking about real-world conditions.

With requirements and scale defined, you can sketch the high-level design. Start with a simple diagram showing the main services and how they connect. Use boxes for services (e.g., Web Server, Application Server, Database) and arrows to show the flow of requests.

As you draw, explain your choices. Why a load balancer? "To distribute traffic across our web servers and prevent any single server from being overwhelmed." Why a cache? "To store frequently accessed data, like timeline information, in memory for faster retrieval, reducing the load on our main database."

After sketching the high-level design (HLD), the interviewer will guide you toward a deep dive. They might ask, "How would you scale the database?" or "How does the timeline generation service work?" This is your cue to zoom in on one part of the diagram.

Let's say they ask about scaling the database. You could discuss the trade-offs between vertical and horizontal scaling. For a system with high write traffic, you'd likely propose horizontal scaling via sharding, explaining how you might partition the data (e.g., by UserID). You don't need to write code, but you must be able to articulate the logic and trade-offs of your chosen approach.

In the final 5-10 minutes, you should zoom back out and summarize your design. This is your chance to identify potential bottlenecks and suggest future improvements. A strong finish shows you can think critically about your own work.

For example, you could point out that the timeline generation service could become a bottleneck if a user has millions of followers (the "celebrity problem"). You could then propose solutions, like pre-computing timelines or using a hybrid push/pull model for notifications.

Finally, briefly recap the non-functional requirements you met. "This design is highly available because we have redundant servers behind a load balancer, and it's scalable because we've sharded our database." This ties your entire discussion together, leaving the interviewer with a clear picture of your comprehensive approach.

Now, let's see how well you've absorbed these steps.

Mastering this four-step framework turns a daunting interview into a manageable conversation. It provides the structure you need to confidently tackle any open-ended system design problem.