How to Pass the System Design Interview

Career 👁️ 1 views Last updated Apr 26, 2026

The Terror of the Blank Whiteboard

You have passed the LeetCode algorithms test. You know how to reverse a linked list. But now you are in the final round of the interview loop for a Senior Backend Engineering role. The interviewer hands you a marker (or opens a shared Excalidraw link) and says: "Design Twitter."

You have 45 minutes to design a system that took thousands of engineers a decade to build. Panic sets in. Where do you start? The database? The load balancers? The UI?

The secret to passing a System Design interview is realizing that it is not a test of right answers; it is a test of structured communication and trade-offs. If you design the "perfect" system but do so in silence, you will fail. You must use a rigid, step-by-step framework to guide the conversation.

Step 1: Clarify Requirements (5-7 Minutes)

Never start drawing immediately. "Design Twitter" is a trap. It is incredibly vague on purpose. You must define the scope.

Functional Requirements: What features are we building? "Are we just doing text tweets, or video uploads too? Do we need a timeline feed?" (Assume text only for simplicity unless told otherwise).
Non-Functional Requirements: "Is this system read-heavy or write-heavy? Is High Availability more important than strict Consistency?" (Twitter is massively read-heavy; people read 100x more than they tweet).

Step 2: Capacity Estimation (5 Minutes)

Do some "back of the envelope" math to prove you understand scale. "If we have 100 million Daily Active Users (DAU), and each user views 50 tweets a day, that is 5 billion reads a day. That is roughly 60,000 queries per second (QPS). We absolutely cannot run this on a single database."

Step 3: High-Level API and Data Model (10 Minutes)

Define the strict contract between the frontend and the backend. Write out the exact API endpoints: POST /v1/tweet (Body: userId, content), GET /v1/timeline.

Then, define the Database tables. "We will need a Users table, a Tweets table, and a Follower Relations table." State your database choice and justify it. "Because the relationships between users are complex, a Graph Database or a highly tuned Relational DB makes sense for the follower table, while the tweets themselves could live in a NoSQL Document Store like Cassandra for high write throughput."

Step 4: The Core Architecture & Bottlenecks (20 Minutes)

Now, draw the boxes. Start from the Client -> Load Balancer -> API Gateway -> Web Servers -> Databases. Once the basic flow is down, the interviewer will attack your design: "What happens when Justin Bieber tweets to his 100 million followers? Your system will crash trying to write to 100 million timelines."

This is where you shine. You introduce concepts like Fan-Out on Read vs Fan-Out on Write. "For normal users, we fan-out on write (push their tweet to their followers' timelines in Redis). But for celebrities, we use a hybrid approach. We don't push the tweet to 100M inboxes. Instead, when a user logs in, we pull the celebrity's tweet and merge it into their timeline on the fly."

Step 5: The Wrap Up (3 Minutes)

Acknowledge your system's flaws. Discuss Single Points of Failure (SPOFs). Mention that you would need robust Datadog monitoring, Prometheus metrics, and automated alerts to keep the system healthy. Confidence, clear communication, and the ability to pivot when the interviewer pokes holes in your design is exactly what gets you hired.