Product-scale system design questions are the ones that appear most often in senior FAANG loops: design Twitter, design YouTube, design WhatsApp. They look familiar. That familiarity is a trap.
Most candidates who prepare these questions prepare the happy path. They know how to draw the boxes and name the components. What they do not practice is the 25 minutes of deep diving, trade-off discussion, and failure mode reasoning that comes after the boxes are drawn, which is exactly what the round is actually evaluating.
<cite index="37-1">At L5, what earns a strong hire is proactively identifying the hardest part of the system. "The interesting challenge here is the feed generation. Let me walk through the trade-offs between fan-out on write and fan-out on read."</cite>
This blog covers the most reported product-scale system design questions at Google L5, Meta E5, and Amazon SDE3, with full design walkthroughs at the depth these companies expect.
Company Context: How Each Company Frames These Questions
Google L5: <cite index="42-1">Each round lasts 45 minutes and centres on a single open-ended design problem. Requirements clarification opens the session. You ask targeted questions about functional requirements, non-functional requirements, scale, and constraints.</cite> Google interviewers favour depth over breadth and expect you to choose which components to go deep on without being prompted.
Meta E5: Meta pushes hardest on scale reasoning. Fan-out decisions, write amplification, and what happens when a celebrity user with 50 million followers posts content are the probes that differentiate E5 candidates. Speed matters: Meta expects you to reach the deep dive faster than Google does.
Amazon SDE3: <cite index="30-1">Amazon interviewers like to base questions on Amazon products, so research the main ones thoroughly beforehand.</cite> Amazon frames design decisions around customer impact. The best SDE3 answers at Amazon connect every technical choice back to the customer experience: availability, latency, and reliability are always framed in terms of what the user feels.
Design 1: News Feed (Twitter / Instagram Feed)
Asked at: Meta, Google, Amazon. <cite index="34-1">The fan-out problem is the central challenge. The celebrity problem, where a user with millions of followers posts content, creates a genuinely hard scaling decision. This is the canonical question for understanding feed architecture.</cite>
Requirements Clarification
Functional requirements:
- Users can post content (text, images, links)
- Users follow other users
- Each user sees a feed of posts from people they follow, in reverse chronological order
- Feed loads in under 500ms
Non-functional requirements:
- 500 million daily active users
- Average user follows 300 people
- Peak write rate: 5 million posts per second globally
- Read-to-write ratio is approximately 100:1 (feeds are read far more than posts are written)
High-Level Architecture
Client
|
API Gateway
|
Write Service ---------> Post Database (distributed, sharded by user_id)
| |
| Message Queue (Kafka)
| |
| Fan-out Service
| / \
| [Regular users] [Celebrity users]
| | |
| Feed Cache Fetch-on-read
|
Read Service <-------- Feed Cache (Redis)
Deep Dive: Fan-out on Write vs. Fan-out on Read
This is the central design decision. It must be discussed explicitly and at depth.
Fan-out on write (push model): When a user posts, the post is immediately written to the feed cache of every follower. Feed reads are fast (just read the pre-computed cache). But for a user with 10 million followers, a single post triggers 10 million write operations. This is called write amplification.
Fan-out on read (pull model): When a user opens their feed, the system fetches the most recent posts from everyone they follow and merges them. No write amplification. But feed generation at read time is slow and expensive, especially for users who follow many people.
Hybrid model (the right answer at senior level): Use fan-out on write for regular users (most followers under 10,000). Use fan-out on read for celebrity users (followers above a threshold). When a regular user opens their feed, it is served directly from their pre-computed cache. Celebrity posts are fetched separately at read time and merged in.
<cite index="37-1">Proactively identifying this as the interesting challenge and walking through the trade-offs between fan-out on write and fan-out on read is the signal that earns a strong hire at L5.</cite>
Deep Dive: Feed Cache
Each user's feed cache holds the 200 to 500 most recent post IDs from people they follow. Use Redis with a sorted set per user keyed by timestamp.
Cache structure:ZADD feed:{user_id} {timestamp} {post_id}
Feed reads: ZREVRANGE feed:{user_id} 0 49 returns the 50 most recent posts.
Post content is stored separately and fetched by post ID after the feed IDs are retrieved. This keeps the feed cache lean.
Eviction: Set a max size per user feed (e.g., 500 posts). When a new post is added to a feed with 500 entries, evict the oldest.
Deep Dive: The Celebrity Problem
A user with 50 million followers posts content. Fan-out on write would queue 50 million cache writes. Even at high throughput, this takes minutes. The user's followers would see the post significantly delayed.
The hybrid model solves this: celebrity posts are not pre-computed into follower feeds. Instead, when a follower's feed is requested, the system checks a celebrity posts table and merges recent celebrity posts with the pre-computed feed from regular followees.
How to identify a celebrity: Maintain a threshold (e.g., 500,000 followers). When a user crosses this threshold, flag them as a celebrity in a user metadata table. The fan-out service checks this flag before deciding which model to use.
Failure Modes to Raise
Fan-out service lag: During peak traffic, the fan-out queue builds up and follower feeds lag behind. Mitigate with auto-scaling on the fan-out workers and a priority queue that processes celebrity accounts last (since they use read-time fetch anyway).
Feed cache eviction during peak reads: During a major event, a celebrity's post triggers a massive read spike. The celebrity post lookup table must be cached separately and backed by a read replica to avoid hitting the primary database.
User opens app for the first time in weeks: Their feed cache is cold or stale. Use a lazy backfill: generate the feed from the post database on first request and populate the cache. Mark the feed as "rebuilding" and return the first page immediately while the rest is backfilled asynchronously.
Design 2: Video Streaming Platform (YouTube)
Asked at: Google (very high frequency), Amazon, Netflix. Tests CDN strategy, video upload pipeline, adaptive streaming, and search at scale.
Requirements Clarification
Functional requirements:
- Users upload videos
- Videos are available for streaming after processing
- Users search for videos by title, description, tags
- Comments and likes on videos
Non-functional requirements:
- 500 hours of video uploaded every minute
- 1 billion video views per day
- 99.99% availability for video playback
- Video start latency under 2 seconds at p95
High-Level Architecture
Upload Client
|
Upload Service -> Raw Video Storage (S3 or GCS)
|
Transcoding Pipeline (async, worker fleet)
|
Processed Video Storage (multiple resolutions)
|
CDN (geographically distributed edge nodes)
|
Streaming Client (adaptive bitrate)
Deep Dive: Transcoding Pipeline
When a video is uploaded, it cannot be served immediately. It must be transcoded into multiple resolutions and formats to support different devices and network conditions.
Pipeline stages:
- Raw video lands in object storage (S3)
- An event is published to a message queue (Kafka or SQS)
- Transcoding workers pick up the job and produce multiple resolution outputs: 144p, 360p, 480p, 720p, 1080p, 4K where applicable
- Transcoded files are stored back in object storage, indexed by video ID and resolution
- Metadata (available resolutions, duration, thumbnail) is updated in the video metadata database
- CDN origins pull from object storage on first request for each file, then cache at the edge
Why async: Transcoding a 1-hour video can take minutes to hours depending on resolution. Blocking the upload response on transcoding completion would create unacceptable upload latency and complex timeout handling. The async pipeline allows the upload to succeed immediately and the video to become available progressively as resolutions are processed.
Deep Dive: Adaptive Bitrate Streaming
Video is not streamed as a single file. It is divided into small segments (typically 2 to 10 seconds each) and served using protocols like HLS (HTTP Live Streaming) or MPEG-DASH.
The client player monitors available bandwidth continuously. When bandwidth drops, it requests the next segment at a lower resolution. When bandwidth improves, it switches back up. This is adaptive bitrate streaming.
Why this matters for the design: The transcoding pipeline must produce segmented versions at each resolution, not just full-file versions. A manifest file (.m3u8 for HLS) lists all available segments and resolutions. The player fetches the manifest first, then requests individual segments based on current network conditions.
Deep Dive: CDN Strategy
With 1 billion views per day, serving video from a central origin is not viable. CDN edge nodes cache video segments geographically close to viewers.
Cache hit rate optimisation: Popular videos are pre-positioned at edge nodes (push CDN). Less popular videos are fetched from origin on first request and cached at the edge for subsequent requests (pull CDN).
Long-tail problem: The majority of YouTube views are on popular content, but the majority of unique videos are long-tail (rarely watched). Long-tail videos cannot justify CDN pre-positioning cost. Serve them from regional origin nodes closer to the viewer than the global origin.
Deep Dive: Video Search
Searching across hundreds of millions of videos in real time requires an inverted index. Title, description, and tags are tokenised and indexed. Search queries are matched against the index and results are ranked by relevance signals (view count, recency, engagement rate).
At SDE3, interviewers probe the indexing pipeline: when a video is uploaded and metadata is set, an event triggers an indexing job that updates the search index. Eventual consistency between the video being available and it appearing in search results (typically seconds to minutes) is acceptable and should be stated explicitly.
Failure Modes to Raise
Transcoding worker failure mid-job: The job must be idempotent and retriable. Use a message queue with visibility timeout: if a worker does not acknowledge completion within the timeout, the job is re-queued and another worker picks it up.
CDN node failure: The client retries the segment request against a different CDN point of presence. The player handles this transparently. Video playback may stutter for one segment during failover.
Upload corruption: Compute a checksum of the uploaded file and verify it against the checksum sent by the client at upload time. Reject and request re-upload on mismatch before the transcoding pipeline begins.
Design 3: Messaging System (WhatsApp)
Asked at: Meta (very high frequency), Amazon, Google. <cite index="34-1">The real-time delivery requirement, online and offline state management, and group chat mechanics push this firmly into intermediate territory at the SDE2 level but become a deep design exercise at SDE3 because of the failure mode complexity.</cite>
Requirements Clarification
Functional requirements:
- One-to-one messaging
- Group messaging (up to 1000 members per group)
- Message delivery receipts (sent, delivered, read)
- Online/offline presence indicators
- Media messages (images, videos, documents)
Non-functional requirements:
- 2 billion active users
- 100 billion messages per day
- Messages delivered in under 100ms when both parties are online
- Messages must not be lost even if the recipient is offline for days
High-Level Architecture
Client A Server Cluster Client B
| | |
|---WebSocket connection------->|<----WebSocket connection----|
| | |
|---- send message ----------->| |
| Message Service |
| | |
| Message Store (persisted) |
| | |
| [B online?] |
| Yes: push via WebSocket----------------->|
| No: store in offline queue |
Deep Dive: Connection Management
Each client maintains a persistent WebSocket connection to a chat server. At 2 billion active users, even with only 20% online simultaneously, that is 400 million concurrent WebSocket connections.
No single server can hold 400 million connections. Distribute connections across a large fleet of stateful connection servers. Use a connection registry (stored in Redis) that maps user ID to the server holding their connection.
When Server A receives a message from Client A destined for Client B:
- Look up Client B's connection server in the registry
- If B is online, forward the message to B's connection server, which pushes it to B's WebSocket
- If B is offline, store the message in a persistent message queue for B
Deep Dive: Message Persistence and Delivery Guarantees
Messages must not be lost. Every message is written to a persistent message store before an acknowledgement is sent to the sender. This means the send flow is:
- Client A sends message
- Server writes to message store (replicated, durable)
- Server sends "sent" receipt to Client A
- Server attempts delivery to Client B
- On successful delivery, send "delivered" receipt to Client A
- When Client B opens and reads the message, send "read" receipt to Client A
Why this order matters: If the server attempted delivery first and then crashed before writing to the message store, the message would be lost. Writing to the durable store first guarantees at-least-once delivery.
Deep Dive: Group Messaging
Group messaging with 1000 members is a fan-out problem. When a user sends a message to a group:
Option 1: Fan-out on write to online members. Look up all 1000 group members. Check which are online (via the connection registry). Push directly to the connection servers of online members. Store in the offline queue for offline members.
Option 2: Fan-out on read. Store the message once in a group message store. Each member fetches new messages by polling or via a group subscription model.
Which to choose at SDE3: Fan-out on write to online members for low latency delivery. Fan-out on read (group subscription) for offline members to avoid a 1000-entry queue per message. State this explicitly as a hybrid approach and justify why.
Deep Dive: Media Handling
Images and videos are not sent through the chat servers. They are:
- Uploaded directly to object storage (S3 equivalent) by the sender
- A message containing only the media URL and metadata is sent through the chat server
- The recipient downloads the media directly from object storage (via CDN for images)
This offloads binary transfer from the chat servers entirely, keeping the message path lightweight and fast.
Failure Modes to Raise
Connection server crash: 10,000 users lose their WebSocket connections. Clients detect the disconnection and reconnect to any available server. The connection registry is updated with the new server assignment. Messages in the offline queue are delivered upon reconnection.
Message store partition: During a network partition, some replicas of the message store may not be reachable. Use a quorum write policy: the message is only acknowledged to the sender when it has been written to a majority of replicas. This prevents the sender from seeing a "sent" receipt for a message that might be lost.
Thundering herd on reconnect: When a server crashes and 10,000 clients reconnect simultaneously, the login and connection setup traffic spikes. Use exponential backoff with jitter on client reconnection to spread the reconnect load over 30 to 60 seconds.
The Signal That Separates SDE3 Hires From SDE2 Hires
Every candidate who reaches an SDE3 system design round knows what a CDN is and why you would use a message queue. That knowledge is table stakes.
The signal interviewers are looking for is whether you can reason about the system the way someone who has built and operated it would. That means:
Raising the thundering herd problem before being asked. Knowing that fan-out on write breaks at celebrity scale and having a specific hybrid solution ready. Understanding that async transcoding pipelines need idempotent jobs with visibility timeouts, not just "a queue."
This kind of reasoning does not come from reading system design books. It comes from explaining your designs out loud to engineers who push back, ask about failure modes, and do not let you stay on the happy path.
At Intervue.io, senior system design sessions are run by engineers who have been inside real FAANG and product company hiring loops at this level. The questions they ask in the mock session are the same questions that will decide your offer.
Visit intervue.io to book a senior system design mock session.
FAQs
Is it necessary to design all three systems (feed, YouTube, messaging) for SDE3? No. You will be asked one question per round. But these three represent the canonical product-scale design problems and between them cover all the patterns (fan-out, CDN, adaptive streaming, WebSocket connection management, offline queuing) that appear across FAANG senior loops. Understanding all three deeply prepares you for the full range.
How do I handle it when I do not know a specific technology the interviewer mentions? Say so directly: "I am not deeply familiar with that specific implementation but I understand the category of problem it solves. Let me walk through how I would approach it using what I know." Senior interviewers respect intellectual honesty. Bluffing on technology knowledge at SDE3 level is immediately detectable.
How much time should the fan-out discussion take in a news feed design? 10 to 15 minutes at minimum. The fan-out decision is the most technically interesting part of the news feed design and is where SDE3 interviewers probe hardest. Treating it as a one-sentence decision ("I would use fan-out on write") rather than a full trade-off discussion is the most common failure mode in feed design rounds at senior level.
Does the WhatsApp design need end-to-end encryption at SDE3? Mention it as a consideration and explain the key exchange mechanism at a high level (each client generates a key pair; the public key is stored on the server; messages are encrypted with the recipient's public key by the sender). You do not need to go deep on cryptography. Raising it unprompted signals awareness of production concerns beyond the functional design.
How does the YouTube design differ between Google and Amazon interviews? At Google, the interviewer will probe transcoding pipeline depth and adaptive bitrate mechanics. At Amazon, the framing shifts to customer impact: "What does a 2-second video start latency mean for viewer retention?" and "How does your CDN strategy handle a live event with 10 million concurrent viewers?" Both require the same technical knowledge but different emphasis.
Summary
The most reported product-scale system design questions at SDE3 level across Google, Meta, and Amazon:
News Feed: Fan-out on write for regular users, fan-out on read for celebrities, hybrid model is the right answer. Feed cache using Redis sorted sets. Celebrity threshold determines routing.
YouTube: Async transcoding pipeline with idempotent retriable jobs. Adaptive bitrate streaming with HLS segments. CDN pre-positioning for popular content, pull model for long-tail. Inverted index for search with eventual consistency.
WhatsApp: WebSocket connections with a connection registry in Redis. Write to durable message store before acknowledging sends. Hybrid fan-out for group messaging. Media offloaded to object storage, not through chat servers.
At SDE3, the deep dive and failure mode discussion is where offers are decided. Know the happy path well enough to cover it in 10 minutes. Spend the rest of the session on depth.
