In the previous lesson, we covered what interviewers actually evaluate. Now we need a repeatable structure that ensures you hit all five dimensions — Problem Exploration, Technical Depth, Trade-off Analysis, Communication, and Pragmatism — in every single interview.
Without a framework, most candidates fall into one of two failure modes: they spend 20 minutes on requirements and run out of time for the deep dive, or they jump straight to drawing boxes and miss the requirements entirely. Both are fatal.
The framework in this lesson is not a rigid script. It is a flexible structure that keeps you on track while allowing you to adapt to any problem the interviewer throws at you.
The 4-Phase Framework
A typical system design interview is 40-45 minutes. Here is how to allocate that time:
The time splits are approximate. If the interviewer wants to spend more time on deep dives, compress the high-level design. If they want to explore requirements more, that is fine too. The key is being intentional about where you spend your time.
Let us walk through each phase in detail.
Phase 1: Requirements Gathering (5 minutes)
This is where you demonstrate Problem Exploration. Your goal is to go from a vague prompt like “Design Twitter” to a concrete, scoped set of requirements that you and the interviewer agree on.
Functional vs Non-Functional Requirements
Every system has two types of requirements, and you need to explicitly address both.
How to Run the Requirements Phase
Start by restating the problem to confirm you understand the prompt:
"So we're designing a system like Twitter — a social platform where users
can post short messages, follow other users, and see a feed of posts from
people they follow. Is that the right scope?"Then systematically work through functional requirements:
"Let me nail down the core features:
1. Users can create posts (text only, or also images/video?)
2. Users can follow other users
3. Users see a home feed — posts from people they follow
4. Is there a search feature? Hashtags? Trending topics?
For this interview, I'd like to focus on the core three: posting,
following, and the home feed. I'll note search and trending as
extensions we can discuss in the wrap-up. Sound good?"Then non-functional requirements:
"For scale, I'll assume:
- 500M total users, 200M DAU
- Each user follows ~200 people on average
- A read-heavy system: maybe 10x more feed reads than new posts
- Feed should load in under 200ms (p99)
- Availability over consistency — it's OK if a post takes a few
seconds to appear in all followers' feeds
- Posts are immutable once created (simplifies our data model)"The Scoping Decision
One of the most powerful moves in the requirements phase is explicitly scoping out features you will not cover. This shows pragmatism and time management awareness.
"I'm going to defer the following for now and focus on the core flow:
- Direct messaging (separate system)
- Media upload pipeline (would add significant complexity)
- Ads and monetization (orthogonal to the core design)
- Analytics and recommendations
If we have time, I'd love to discuss how the feed ranking would work."Interviewers love this. It shows you understand that real engineering is about making choices, not boiling the ocean.
Common Mistakes in Phase 1
Asking too many questions. If you spend 10 minutes on requirements, you have lost. Limit yourself to 5-8 targeted questions, state reasonable assumptions for the rest, and move on.
Asking trivial questions. “Should users have profiles?” is not a useful question. “What’s the expected read-to-write ratio?” is.
Not writing things down. State your requirements explicitly and confirm them. This creates a shared contract between you and the interviewer that you can reference later.
Phase 2: High-Level Design (10 minutes)
This is where you build the skeleton of your system. Your goal is to go from requirements to a working architecture that handles the main use cases. Not optimized, not scaled — just working.
The Design Progression
Follow this sequence. Each step builds on the previous one.
Step 1: Identify Core Entities
Start by listing the main data objects in your system:
"Our core entities are:
- User: id, username, profile info
- Post: id, author_id, content, timestamp
- Follow: follower_id, followee_id, timestamp
- Feed: a derived view of posts for a specific user"This takes 30 seconds but frames everything that follows. Your entities inform your APIs, your APIs inform your data model, and your data model informs your architecture.
Step 2: Define API Contracts
Sketch the main API endpoints. You do not need full REST specifications — just enough to show the read and write paths:
Core APIs:
POST /posts
Body: { content: string }
Returns: { post_id, timestamp }
GET /feed?user_id={id}&cursor={cursor}&limit=20
Returns: { posts: [...], next_cursor }
POST /follow
Body: { followee_id: string }
Returns: { success: boolean }
GET /users/{id}/posts?cursor={cursor}
Returns: { posts: [...], next_cursor }Notice the cursor-based pagination. Mentioning this shows you have thought about real-world API design and not just the happy path.
Step 3: Data Model
Choose your database and sketch the schema. This is where you make your first significant design decision:
"For the core data model, I'll use a relational database for users and
follows — the relationships are natural and we need strong consistency
for the follow graph.
Users table:
id (PK), username, display_name, created_at
Follows table:
follower_id, followee_id, created_at
PK: (follower_id, followee_id)
Index: (followee_id) — for 'who follows me' queries
Posts table:
id (PK), author_id (FK), content, created_at
Index: (author_id, created_at DESC) — for user timeline
For the feed, I'll discuss the strategy in the deep dive, since this
is the core challenge of the system."Step 4: Basic Architecture
Now draw the box diagram. Start simple:
Architecture:
Client → Load Balancer → API Servers → Database (PostgreSQL)
→ Cache (Redis)
→ Feed Service (separate)
→ Object Store (S3 for media)At this point, you have a working system. It handles the main use cases. It is not optimized, it probably does not scale to 200M DAU, and there are obvious bottlenecks. That is perfectly fine. The skeleton exists, and now you can stress-test it.
Common Mistakes in Phase 2
Over-engineering the initial design. Do not add Kafka, multiple microservices, or a data pipeline in the high-level phase. Start simple. Complexity should be motivated by specific requirements, not added preemptively.
Skipping the data model. Many candidates draw boxes and arrows but never discuss what data lives where or how it is structured. The data model is often where the hardest problems live.
Drawing too many boxes. If your initial diagram has 15 services, you have gone too far. Start with 3-5 components and add more only when the deep dive reveals they are needed.
Phase 3: Deep Dive (20 minutes)
This is where interviews are won or lost. You have 20 minutes to demonstrate Technical Depth and Trade-off Analysis on the hardest parts of the system.
Choosing What to Deep Dive On
You cannot deep dive on everything. Pick 2-3 areas where:
- The problem has genuine complexity
- You have strong knowledge
- The interviewer has shown interest
For our Twitter example, the best deep dive topics are:
- Feed generation: Fan-out-on-write vs fan-out-on-read (this is the core challenge)
- Scaling the follow graph: Handling users with millions of followers
- Data partitioning: How to shard posts and feeds
How to Structure a Deep Dive
For each topic, follow this pattern:
1. State the problem clearly:
"The core challenge with the feed is: when a user opens their home
feed, we need to assemble posts from all the people they follow,
sorted by time (and eventually, relevance). At our scale of 200M DAU
with users following an average of 200 people, how do we generate
feeds efficiently?"2. Present alternatives:
"There are two fundamental approaches:
Fan-out-on-write (push model):
When a user creates a post, we precompute and write that post
into the feed of every follower.
- Pro: Feed reads are extremely fast (just read from a precomputed list)
- Con: Write amplification — a user with 10M followers triggers 10M writes
- Con: Wasted work for users who never check their feed
Fan-out-on-read (pull model):
When a user requests their feed, we query all the people they follow,
get their recent posts, merge, and sort.
- Pro: No write amplification, no wasted work
- Con: Feed generation is slow (hundreds of queries per request)
- Con: Hard to scale read path at high QPS"3. Make a justified decision:
"I'll use a hybrid approach, which is what Twitter actually evolved to:
- For regular users (< 10K followers): fan-out-on-write. The write
amplification is bounded and feed reads are instant.
- For celebrity users (> 10K followers): fan-out-on-read. We fetch
their posts at read time and merge them into the precomputed feed.
This gives us the fast reads of the push model for 99% of cases while
avoiding the write explosion for the 1% of users who have millions of
followers.
The feed service maintains a sorted list per user in Redis. When a
regular user posts, an async worker fans out the post to all follower
feeds. The Redis sorted set is keyed by user_id and scored by
timestamp, giving us O(log n) insertion and O(k) retrieval for the
top-k feed items."4. Address follow-up concerns:
"A few things we'd need to handle:
1. Feed cache eviction: We can't keep feeds forever. We'd store the
last 800 posts per user and fall back to the read path for older
history.
2. New follow handling: When user A follows user B, we need to
backfill B's recent posts into A's feed. This is an async job.
3. Consistency: A user who just posted should see their own post
immediately. We can handle this with a read-your-writes check —
merge the user's own recent posts client-side.
4. Hot partitions: Celebrity posts will hammer specific Redis nodes.
We can use multiple replicas and route read requests across them."This single deep dive demonstrates all five evaluation dimensions: you explored the problem, showed technical depth, analyzed trade-offs, communicated clearly, and proposed pragmatic solutions.
Time Management During Deep Dives
Spend roughly 7-10 minutes on your primary deep dive and 5-7 minutes each on secondary topics. If the interviewer is engaged and asking follow-up questions, that is a great sign — lean into it. If they seem satisfied, move on.
Watch for interviewer signals:
- “That makes sense, what else would you consider?” → They want you to move to a new topic
- “What about [specific concern]?” → They want you to go deeper on that concern
- “How would you handle [edge case]?” → They are testing depth, dive in
- “Let’s move on to…” → Respect their redirect immediately
Common Mistakes in Phase 3
Staying shallow across many topics. Covering 6 areas superficially is worse than covering 2 areas deeply. Interviewers want to see how you think, and that requires depth.
Ignoring the interviewer’s interests. If the interviewer keeps asking about data consistency, that is where the deep dive should go. Do not fight it.
Not discussing failure modes. “What happens when this component goes down?” is a question you should proactively answer, not wait to be asked.
Phase 4: Wrap-Up (5 minutes)
The wrap-up is your chance to leave a strong final impression and demonstrate forward-thinking awareness.
What to Cover in the Wrap-Up
1. Summarize key decisions:
"To recap: We designed a Twitter-like system with a hybrid fan-out
approach — push for regular users, pull for celebrities. The feed
is precomputed in Redis for fast reads, with async workers handling
the fan-out. We're using PostgreSQL for the core data model and S3
for media storage."2. Acknowledge what you deferred:
"Things I'd want to address in a real project that we didn't cover:
- Search and indexing (likely Elasticsearch)
- Media upload and processing pipeline
- Feed ranking beyond chronological
- Spam and abuse detection
- Monitoring and alerting"3. Discuss scaling and evolution:
"As the system grows, I'd consider:
- Sharding the posts table by user_id
- Moving from a single Redis cluster to region-specific clusters
- Adding a CDN for frequently accessed content
- Introducing a data pipeline for analytics and ML features"4. Ask for feedback:
"That's my design at a high level. Are there areas you'd like me to
explore further, or concerns about any of the decisions I made?"This final question is powerful. It signals confidence and openness to feedback — exactly the qualities teams want in a colleague.
Example Walkthrough: Applying the Framework
Let us apply the entire framework to a simpler problem to see it in action end-to-end.
Problem: “Design a URL shortening service like bit.ly.”
Phase 1: Requirements (3 minutes)
Functional:
- Users submit a long URL, get back a short URL
- Visiting the short URL redirects to the original
- Custom aliases (optional, defer to extension)
- Analytics on click count (defer to extension)
Non-Functional:
- 100M new URLs per month, 10B redirects per month
- Redirect latency < 50ms (p99)
- URLs never expire by default
- High availability — a broken redirect is unacceptable
- Read-heavy: 100:1 read-to-write ratioPhase 2: High-Level Design (5 minutes)
Entities: URL (id, short_code, long_url, created_at, user_id)
APIs:
POST /shorten { long_url } → { short_url }
GET /{short_code} → 301 Redirect to long_url
Data Model:
URLs table:
short_code (PK), long_url, created_at, user_id
Index: (user_id) for "my URLs" queries
Architecture:
Client → CDN/Cache → Load Balancer → App Servers → DB (NoSQL)
→ Cache (Redis)
Short code generation:
Base62 encoding of a counter (7 chars = 3.5 trillion unique codes)Phase 3: Deep Dive (10 minutes)
Deep Dive 1: ID Generation
- Counter-based with base62 encoding
- Use a distributed counter (e.g., ZooKeeper or pre-allocated ranges)
- Each server gets a range of 1M IDs, generates locally, requests new
range when exhausted
- No coordination needed between servers during normal operation
- Trade-off: Sequential IDs are predictable (security concern).
Mitigation: Shuffle the base62 encoding or use a bijective function
Deep Dive 2: Redirect Performance
- Cache the mapping in Redis (key: short_code, value: long_url)
- Cache hit rate should be very high (80/20 rule: 20% of URLs get
80% of traffic)
- CDN for the most popular URLs (configure 301 caching)
- Database as fallback for cache misses
- Total redirect path: CDN hit → 5ms, Cache hit → 15ms,
DB read → 30msPhase 4: Wrap-Up (2 minutes)
Summary: Distributed counter for ID generation, Redis cache for fast
redirects, NoSQL for persistent storage. 301 redirects enable CDN and
browser caching.
Extensions: Custom aliases, analytics pipeline, URL expiration,
rate limiting, abuse detection.Time Management Tips
-
Set a mental timer. After 5 minutes on requirements, explicitly transition: “I think I have enough context. Let me start sketching the high-level design.”
-
Do not ask permission for every step. Instead of “Should I talk about the data model now?”, just say “Let me walk through the data model” and start drawing.
-
Verbally flag your time awareness. “I want to make sure we have time for the deep dive on feed generation, so let me quickly sketch the high-level architecture first.”
-
Know when to stop a deep dive. If you have been on one topic for 12+ minutes, it is time to wrap it up unless the interviewer is actively asking follow-up questions.
-
Prioritize ruthlessly. If you can only deep dive on one thing, make it the hardest, most interesting part of the system. That is where the points are.
What To Do Next
You now have a repeatable framework for structuring any system design answer. The next lesson covers a critical skill that feeds into every phase of this framework: back-of-envelope estimation. Being able to quickly estimate QPS, storage, and bandwidth helps you make informed design decisions and demonstrates quantitative thinking.
Key takeaways:
- Use the 4-phase framework: Requirements (5 min) → High-Level Design (10 min) → Deep Dive (20 min) → Wrap-up (5 min)
- Follow the design progression: Entities → APIs → Data Model → Architecture → Deep Dives
- Scope aggressively in Phase 1 — depth beats breadth
- The deep dive phase is where interviews are won or lost — pick 2-3 hard problems and go deep
- Always wrap up with a summary, deferred items, and a forward-looking discussion