Sections
Section · Overview
The 4-step framework
Every system design interview is different, but a great one is structured. Alex Xu's chapter prescribes four phases over a roughly 45-minute window: scope the problem, propose a high-level design, drill into one or two components, then wrap up. Time pressure isn't the test — coherence is.
45-minute time budget
~55 min total
↑ Hover or click any segment above to inspect a phase
Step 1 · Scope
3–10 minUnderstand the problem & establish design scope
Real-world system design is open-ended. Before drawing anything, agree with the interviewer on what is actually being built — features, scale, traffic shape, constraints. Right answers solve the right problem.
Common Don't
Don't jump into a solution without clarifying the requirements and assumptions.
- ▸Ask what features matter most
- ▸Quantify users, traffic, growth
- ▸Surface non-functional requirements (latency, availability, consistency)
- ▸Confirm the scope you'll address in the remaining time
All phases at a glance
Reference summaryThe same four phases as the bar above, side-by-side. Read-only.
Step 1
3–10 minScope
Understand the problem & establish design scope
- ▸Ask what features matter most
- ▸Quantify users, traffic, growth
- ▸Surface non-functional requirements (latency, availability, consistency)
- ▸Confirm the scope you'll address in the remaining time
Step 2
10–15 minHigh-level
Propose high-level design and get buy-in
- ▸Draw the major components on the whiteboard
- ▸Trace one or two key request flows
- ▸Cover APIs and data model at a sketch level
- ▸Do back-of-envelope numbers if scale demands it
Step 3
10–25 minDeep dive
Design deep dive
- ▸Pick the bottleneck component(s)
- ▸Compare 2+ approaches with trade-offs
- ▸Address failure modes and recovery
- ▸Quantify the impact at scale
Step 4
3–5 minWrap-up
Wrap up
- ▸Summarize the proposed design in one minute
- ▸Call out error cases and how the system handles them
- ▸Discuss monitoring and metrics
- ▸Identify the next bottleneck and how you'd address it
What the framework is NOT
- ✗A script. The interviewer drives where to drill.
- ✗A timer. Phase budgets are guides; running long means the next phase pays.
- ✗A way to reach 'the' right answer — there are several.
Section · Worked example
News Feed walkthrough
Alex Xu uses a news-feed system to demonstrate the four-step framework end-to-end. Step through Figures 3-1 → 3-4 below. Each step shows the architectural blocks the book introduces, with the new ones highlighted, plus commentary on what just changed and why.
The brief
A user opens the app and sees a stream of posts from people they follow, in reverse chronological order. New posts from a user must reach their followers' feeds within seconds. The system must support tens of millions of daily active users at peak.
Step 1 — clarifying questions the candidate would ask
- ?Is this a mobile app, a web app, or both?
- ?What are the most important features — feed reading, posting, both?
- ?Is the feed sorted reverse-chronologically, or by some ranking signal?
- ?Can a post contain images or video, or is it text-only?
- ?How many friends/follows does a typical user have?
- ?What's the daily active user volume we're sizing for?
- ?What's the traffic shape — steady, bursty, peak hours?
Figure 3-1 — Feed publishing, high-level
1 / 4Step 2: high-level design for the publish flow.
Edge tier
Compute tier
Data tier
Click any block above to see its description
Commentary
When a user publishes a post, the request hits DNS, then a load balancer, then the stateless web tier. From there it splits three ways: Post Service writes the post itself (cache + DB), Fanout Service decides where the post should land in followers' feeds, and Notification Service pushes alerts. This is the publish blueprint — no detail yet, just the seams.
What to notice
- ▸Three downstream services off the web tier — write, fanout, notify
- ▸Post Service owns its own cache + DB pair
- ▸Fanout writes into the News Feed Cache, not the Post DB
Step 1 / 4
Section · Reference
Block bank
Every block that appears in the news-feed reference design, grouped by tier. These are the architectural primitives the candidate assembles in Step 2 — the alphabet, not the sentence. Inside the Mock Interview section, this same set is the palette you'll pick from when you role-play the design phase.
Edge
3 blocksWhere traffic enters the system — DNS, CDN, load balancing.
DNS
Resolves the user's request hostname to an IP — the very first hop before any traffic reaches your infrastructure.
CDN
Caches static assets (images, video thumbnails) at the edge, close to users. Added in Figure 3-4 to absorb media bandwidth and latency.
Load Balancer
Distributes incoming requests across web servers. Provides the seam where TLS termination, health checks, and basic routing live.
Compute
8 blocksStateless services that execute application logic.
Web Servers
Stateless application tier. Receives the request, validates it, and dispatches to downstream services.
Authentication
Verifies the user's auth token before any service work happens. Typically lives at the web-server boundary.
Rate Limiting
Caps how many requests a single user (or token) can issue per unit time. Protects downstream services from abuse and runaway clients.
Post Service
Owns the create-post path: validation, persistence to the post store, and emitting a fanout event.
Fanout Service
Decides where a new post should land. Looks up the author's followers and queues per-recipient delivery work.
Fanout Workers
Pull from the message queue and push the post into each recipient's News Feed Cache. Scale horizontally with follower count.
Notification Service
Pushes new-post pings to followers' clients (mobile push, web push). Lives off the publish path to avoid blocking the write.
News Feed Service
Owns the read path: assembles the user's feed by reading from the News Feed Cache, hydrates with post data, returns to the client.
Data
6 blocksStateful stores and caches — the system's memory.
Post Cache
In-memory cache of recently-written posts. Absorbs hot reads so the post DB only sees cold or evicted traffic.
News Feed Cache
Per-user list of post IDs that make up the feed. Read-optimized, written by fanout workers, read by the News Feed Service.
User Cache
Hot-path cache for user profile data (name, avatar, settings). Hydrates feed responses without hitting the User DB on every render.
Post DB
Durable store for post content. Sharded by post ID or author ID at scale. The system of record behind Post Cache.
User DB
Durable store for user profile data. Smaller and lower-traffic than Post DB, but appears on every authenticated request.
Graph DB
Stores the follower / friend graph. Fanout queries it to find every recipient when a user posts. Specialized stores (Neo4j, custom) shine here.
Async
1 blockDecoupling layer between producers and consumers.
Message Queue
Decouples Fanout Service from Fanout Workers. Buffers spikes, enables retry, lets the publish-side return as soon as the work is enqueued.
Section · Behavioral guardrails
Dos & Don'ts
The framework gets you the right shape. The behaviors below get you the right impression. Click any card to expand the rationale, and note which phases each rule applies to — Mock Interview Mode will surface these contextually as you role-play.
Do
7 rulesDon't
6 rulesSection · Live role-play
Mock interview
Walk through a 45-minute system design interview on the news-feed problem. The four phases gate themselves with a soft timer; the interviewer prompts at each step; behavioral nudges surface when you skip a clarifying question or run long. Leave the section and come back any time — your progress is saved.
Scenario
Design a news feed system
A user opens the app and sees a stream of posts from people they follow, in reverse chronological order. New posts from a user must reach their followers' feeds within seconds. The system must support tens of millions of daily active users at peak.
What to expect
- ▸Four timed phases over ~45 minutes — Scope, High-level, Deep dive, Wrap-up.
- ▸Soft timer — warnings and nudges, but you control when to advance.
- ▸Wrap-up shows your transcript and a comparison against the book's reference.
Sections
Section · Overview
The 4-step framework
Every system design interview is different, but a great one is structured. Alex Xu's chapter prescribes four phases over a roughly 45-minute window: scope the problem, propose a high-level design, drill into one or two components, then wrap up. Time pressure isn't the test — coherence is.
45-minute time budget
~55 min total
↑ Hover or click any segment above to inspect a phase
Step 1 · Scope
3–10 minUnderstand the problem & establish design scope
Real-world system design is open-ended. Before drawing anything, agree with the interviewer on what is actually being built — features, scale, traffic shape, constraints. Right answers solve the right problem.
Common Don't
Don't jump into a solution without clarifying the requirements and assumptions.
- ▸Ask what features matter most
- ▸Quantify users, traffic, growth
- ▸Surface non-functional requirements (latency, availability, consistency)
- ▸Confirm the scope you'll address in the remaining time
All phases at a glance
Reference summaryThe same four phases as the bar above, side-by-side. Read-only.
Step 1
3–10 minScope
Understand the problem & establish design scope
- ▸Ask what features matter most
- ▸Quantify users, traffic, growth
- ▸Surface non-functional requirements (latency, availability, consistency)
- ▸Confirm the scope you'll address in the remaining time
Step 2
10–15 minHigh-level
Propose high-level design and get buy-in
- ▸Draw the major components on the whiteboard
- ▸Trace one or two key request flows
- ▸Cover APIs and data model at a sketch level
- ▸Do back-of-envelope numbers if scale demands it
Step 3
10–25 minDeep dive
Design deep dive
- ▸Pick the bottleneck component(s)
- ▸Compare 2+ approaches with trade-offs
- ▸Address failure modes and recovery
- ▸Quantify the impact at scale
Step 4
3–5 minWrap-up
Wrap up
- ▸Summarize the proposed design in one minute
- ▸Call out error cases and how the system handles them
- ▸Discuss monitoring and metrics
- ▸Identify the next bottleneck and how you'd address it
What the framework is NOT
- ✗A script. The interviewer drives where to drill.
- ✗A timer. Phase budgets are guides; running long means the next phase pays.
- ✗A way to reach 'the' right answer — there are several.
Section · Worked example
News Feed walkthrough
Alex Xu uses a news-feed system to demonstrate the four-step framework end-to-end. Step through Figures 3-1 → 3-4 below. Each step shows the architectural blocks the book introduces, with the new ones highlighted, plus commentary on what just changed and why.
The brief
A user opens the app and sees a stream of posts from people they follow, in reverse chronological order. New posts from a user must reach their followers' feeds within seconds. The system must support tens of millions of daily active users at peak.
Step 1 — clarifying questions the candidate would ask
- ?Is this a mobile app, a web app, or both?
- ?What are the most important features — feed reading, posting, both?
- ?Is the feed sorted reverse-chronologically, or by some ranking signal?
- ?Can a post contain images or video, or is it text-only?
- ?How many friends/follows does a typical user have?
- ?What's the daily active user volume we're sizing for?
- ?What's the traffic shape — steady, bursty, peak hours?
Figure 3-1 — Feed publishing, high-level
1 / 4Step 2: high-level design for the publish flow.
Edge tier
Compute tier
Data tier
Click any block above to see its description
Commentary
When a user publishes a post, the request hits DNS, then a load balancer, then the stateless web tier. From there it splits three ways: Post Service writes the post itself (cache + DB), Fanout Service decides where the post should land in followers' feeds, and Notification Service pushes alerts. This is the publish blueprint — no detail yet, just the seams.
What to notice
- ▸Three downstream services off the web tier — write, fanout, notify
- ▸Post Service owns its own cache + DB pair
- ▸Fanout writes into the News Feed Cache, not the Post DB
Step 1 / 4
Section · Reference
Block bank
Every block that appears in the news-feed reference design, grouped by tier. These are the architectural primitives the candidate assembles in Step 2 — the alphabet, not the sentence. Inside the Mock Interview section, this same set is the palette you'll pick from when you role-play the design phase.
Edge
3 blocksWhere traffic enters the system — DNS, CDN, load balancing.
DNS
Resolves the user's request hostname to an IP — the very first hop before any traffic reaches your infrastructure.
CDN
Caches static assets (images, video thumbnails) at the edge, close to users. Added in Figure 3-4 to absorb media bandwidth and latency.
Load Balancer
Distributes incoming requests across web servers. Provides the seam where TLS termination, health checks, and basic routing live.
Compute
8 blocksStateless services that execute application logic.
Web Servers
Stateless application tier. Receives the request, validates it, and dispatches to downstream services.
Authentication
Verifies the user's auth token before any service work happens. Typically lives at the web-server boundary.
Rate Limiting
Caps how many requests a single user (or token) can issue per unit time. Protects downstream services from abuse and runaway clients.
Post Service
Owns the create-post path: validation, persistence to the post store, and emitting a fanout event.
Fanout Service
Decides where a new post should land. Looks up the author's followers and queues per-recipient delivery work.
Fanout Workers
Pull from the message queue and push the post into each recipient's News Feed Cache. Scale horizontally with follower count.
Notification Service
Pushes new-post pings to followers' clients (mobile push, web push). Lives off the publish path to avoid blocking the write.
News Feed Service
Owns the read path: assembles the user's feed by reading from the News Feed Cache, hydrates with post data, returns to the client.
Data
6 blocksStateful stores and caches — the system's memory.
Post Cache
In-memory cache of recently-written posts. Absorbs hot reads so the post DB only sees cold or evicted traffic.
News Feed Cache
Per-user list of post IDs that make up the feed. Read-optimized, written by fanout workers, read by the News Feed Service.
User Cache
Hot-path cache for user profile data (name, avatar, settings). Hydrates feed responses without hitting the User DB on every render.
Post DB
Durable store for post content. Sharded by post ID or author ID at scale. The system of record behind Post Cache.
User DB
Durable store for user profile data. Smaller and lower-traffic than Post DB, but appears on every authenticated request.
Graph DB
Stores the follower / friend graph. Fanout queries it to find every recipient when a user posts. Specialized stores (Neo4j, custom) shine here.
Async
1 blockDecoupling layer between producers and consumers.
Message Queue
Decouples Fanout Service from Fanout Workers. Buffers spikes, enables retry, lets the publish-side return as soon as the work is enqueued.
Section · Behavioral guardrails
Dos & Don'ts
The framework gets you the right shape. The behaviors below get you the right impression. Click any card to expand the rationale, and note which phases each rule applies to — Mock Interview Mode will surface these contextually as you role-play.
Do
7 rulesDon't
6 rulesSection · Live role-play
Mock interview
Walk through a 45-minute system design interview on the news-feed problem. The four phases gate themselves with a soft timer; the interviewer prompts at each step; behavioral nudges surface when you skip a clarifying question or run long. Leave the section and come back any time — your progress is saved.
Scenario
Design a news feed system
A user opens the app and sees a stream of posts from people they follow, in reverse chronological order. New posts from a user must reach their followers' feeds within seconds. The system must support tens of millions of daily active users at peak.
What to expect
- ▸Four timed phases over ~45 minutes — Scope, High-level, Deep dive, Wrap-up.
- ▸Soft timer — warnings and nudges, but you control when to advance.
- ▸Wrap-up shows your transcript and a comparison against the book's reference.