System design interviews test your ability to design large-scale distributed systems. Unlike coding interviews, there’s no single “correct” answer—interviewers evaluate your thought process, communication, and trade-off analysis.
What interviewers are looking for:
Can you drive the conversation and ask good questions?
Do you understand scalability and distributed systems?
Can you identify and solve bottlenecks?
Do you make reasonable trade-offs and justify them?
Core Features:□ "What are the most important features to focus on?"□ "Who are the users? What actions can they take?"□ "What does the user flow look like?"Scope:□ "Should we design the entire system or focus on X?"□ "Are there any features we should NOT include?"□ "Mobile app, web, or both?"Data:□ "What data do we need to store?"□ "What are the relationships between entities?"□ "Do we need to support search?"
Copy
Scale:□ "How many users? DAU/MAU?"□ "How many requests per second?"□ "Read-heavy or write-heavy?"Performance:□ "What's the acceptable latency?"□ "What's the availability target? (99.9%?)"Consistency:□ "Is strong consistency required?"□ "Can we tolerate eventual consistency?"Other:□ "Any geographic distribution requirements?"□ "Any compliance/security requirements?"
Copy
Interviewer: "Design Twitter"You: "Before I start, I'd like to clarify a few things.For scope - should I focus on the core features like posting tweets and the timeline, or also include search, trending, and direct messages?For scale - are we designing for Twitter's actual scale of ~500M users, or a smaller subset?For consistency - is it acceptable if a tweet takes a few seconds to appear in all followers' timelines?...Great, so I'll focus on posting and timeline for 500M users with eventual consistency. Let me start with some capacity estimates..."
Say your assumptions out loud! “I’ll assume 86,400 is about 100,000 for easy math…” This shows you understand approximation and makes your calculations easy to follow.
-- Always include:-- 1. Primary key (usually BIGINT or UUID)-- 2. Created/updated timestamps-- 3. Indexes for common queriesCREATE TABLE users ( id BIGINT PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, email VARCHAR(255) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT NOW(), updated_at TIMESTAMP DEFAULT NOW());-- Index for loginCREATE INDEX idx_users_email ON users(email);-- Think about:-- □ What queries will we run?-- □ Which columns need indexes?-- □ How will we shard if needed?-- □ What's the partition key?
Always mention trade-offs. This shows senior thinking:
Decision
Trade-off
SQL vs NoSQL
Consistency vs Scale
Sync vs Async
Latency vs Reliability
Cache
Speed vs Staleness
Denormalization
Read speed vs Write complexity
Microservices
Flexibility vs Complexity
Strong consistency
Correctness vs Availability
Copy
Good answer pattern:"I chose X over Y because [requirement]. The trade-off is [downside], but we can mitigate this by [solution]."Example:"I chose eventual consistency for the timeline because low latency is more important than seeing tweets immediately. The trade-off is users might not see a tweet for a few seconds, but this is acceptable for a social feed."
□ Review the framework (5-5-10-20-5 minutes)□ Memorize key numbers (QPS, latency, storage)□ Practice 3-5 problems end-to-end□ Have a drawing tool ready (Excalidraw, paper)□ Prepare questions to ask□ Review common trade-offs□ Get good sleep!
