System Design Walkthroughs: Twitter, Instagram, WhatsApp, Slack, Zoom, YouTube and Netflix

Ten classic system design interview questions, each walked through the way you would present it in a 45-minute round: what to clarify, the core design, the deep dive interviewers push on and the trade-offs worth saying out loud. They are grouped by the problem underneath: feeds and timelines, messaging, video and streaming, and notifications. Use the table to find the hard part of each, then practice the walkthrough aloud. For more designs, see best system design resources.

How to run any of these in 45 minutes

1. Clarify for five minutes. Pin down the two or three features that matter, the scale (daily users, reads versus writes, data size) and the one non-functional requirement that dominates, usually latency, availability or correctness.
2. Estimate in two. Rough numbers decide the design: requests per second at peak, storage per year, bandwidth for media. Round hard and say your assumptions out loud.
3. Sketch the API and the data model. Three to five endpoints and the main tables or keys. This is where you show you know what has to be stored and how it will be read.
4. Draw the high-level design. Clients, load balancer, stateless services, the stores, caches, queues and the CDN. Walk one request end to end.
5. Spend fifteen to twenty minutes on the deep dive. Each walkthrough below names the part interviewers push on. Lead there before you are asked.
6. Close with trade-offs. What breaks first at ten times the load, what you would monitor, and what you chose not to build.

The walkthroughs below assume this shape. If you are new to the format, start with what a system design interview is; for the broader prep plan, see our system design interview guide.

At a glance: the hard part of each question

Feeds and timelines

Design Twitter

Clarify: posting short posts with media, following, the home timeline and a user's own timeline. Search and trends are usually stretch goals. The workload is read-heavy, often quoted near a hundred reads per write, and the home timeline should load in a couple of hundred milliseconds.

Core design: a post service writes to a sharded store keyed by a time-sortable ID, a graph service holds who follows whom, and a timeline service keeps each active user's home timeline as a cached list of recent post IDs. Reads fetch the ID list, then hydrate posts and authors from caches.

The deep dive is fan-out. Fan-out on write pushes each new post ID into every follower's cached timeline, which makes reads cheap but turns one post from an account with millions of followers into millions of writes. Fan-out on read assembles the timeline at request time, which is cheap to write and slow to read. The answer interviewers want is the hybrid: push for ordinary accounts, and for accounts above a follower threshold merge their recent posts in at read time. Mention that timelines are not precomputed for inactive users and get rebuilt when they return.

Trade-offs to say out loud: timelines are eventually consistent, which is fine; deletes are handled by hydrating IDs at read time; trends come from counting hashtags over sliding windows in a stream processor.

Design Instagram

Clarify: uploading photos and short videos, following, a feed, likes and comments. Stories and Explore are common follow-ups. Storage and bandwidth dominate the estimates, so do them early.

Core design: the client asks for a pre-signed URL and uploads straight to object storage, so media never passes through the API servers. An asynchronous pipeline creates the resolutions and thumbnails each device needs and records the media keys with the post's metadata. A CDN serves every image and video. The feed reuses the timeline machinery from Twitter, with a ranking step on top.

Deep dive: the upload pipeline (resumable uploads for video, a processing queue with retries, deduplication by content hash) and feed ranking (gather candidates from accounts the user follows, score them with a model using engagement features, and serve the ranked page from a cache). Like counts on popular posts are hot keys, so use sharded or approximate counters and replicate hot entries in the cache.

Trade-offs: ranking everything on read is fresh but expensive, so precompute candidates and rank at request time; move old media to cheaper storage tiers; Stories are a separate tray with a 24-hour expiry.

Design a news feed

This is the general form of the Twitter and Instagram questions, and interviewers use it to see whether you can reason about the fan-out choice without a brand name to lean on. Split it into publishing (a user posts) and retrieval (a user opens the feed).

Core design: the post service stores the post and emits an event; fan-out workers read the event from a queue, look up followers and append the post ID to each follower's feed cache; the feed service reads IDs and hydrates them from a content cache, a user cache and counters. Name the cache layers explicitly: feed, content, social graph, actions and counters.

Deep dive: push, pull or hybrid, as above; pagination with a cursor (the last post ID or timestamp seen), never an offset, because the feed changes between requests; ranking, where a model scores candidates and you keep a little randomness for freshness; and edits or deletes, which is why feeds store IDs rather than copies.

Trade-offs: freshness against cost, memory for precomputed feeds against latency, and what you degrade first under load (ranking falls back to reverse-chronological order).

Messaging

Design WhatsApp

Clarify: one-to-one and group messages, sent, delivered and read receipts, online presence, media, end-to-end encryption, and delivery to phones that are offline for hours.

Core design: each phone keeps a persistent connection to a chat server; a session registry maps each user to the server holding the connection; messages route through that registry. If the recipient is offline, the message waits in a store-and-forward queue and is deleted once delivered, and a push notification wakes the phone. Media is uploaded encrypted to object storage and the message carries the key.

Deep dive: end-to-end encryption in the style of the Signal protocol, where the server relays ciphertext and distributes public prekeys but cannot read messages; group messages, where the sender encrypts once with a group key and the server fans out to members; and delivery guarantees, where client-generated message IDs, acknowledgements and deduplication give at-least-once delivery that looks like exactly-once, with a sequence number per conversation for ordering.

Trade-offs: keeping messages only until delivery is private and cheap but makes multi-device sync harder; presence updates are throttled and sent only to contacts who are looking.

Design a chat app

The generic chat question tests the transport and storage choices without the encryption story. Clarify group size, history retention, unread counts and whether offline push is in scope.

Core design: stateful chat servers hold WebSocket connections (long polling only as a fallback); stateless API servers handle sign-in, history and settings; a service-discovery layer assigns each client to a chat server; a message ID generator gives IDs that sort by time within a conversation; and history lives in a wide-column store keyed by conversation and time, which suits append-heavy writes and range reads.

Deep dive: scaling connections (each server holds tens of thousands, so plan for reconnect storms when one dies), sync on reconnect (the client sends the last message ID it saw per conversation and receives the gap), and group fan-out (cap group size, or fan out through the servers that hold members' connections).

Trade-offs: relational storage is easier to query but harder to scale for this write pattern; read receipts in large groups are expensive, which is why many apps limit them.

Design Slack

Slack changes the chat question in four ways: workspaces (many tenants), channels with thousands of members, threads, and permanent, searchable history. Bots and integrations are a common follow-up.

Core design: messages are stored per channel and sharded by workspace; a real-time gateway tier holds client connections and subscribes to the channels its connected users belong to; a search pipeline indexes messages per workspace; a notification service evaluates mentions and each user's settings.

Deep dive: fan-out to a large channel happens at the gateway tier (publish once to the channel topic, and each gateway delivers to its own connected members) rather than one write per member; unread state is a last-read pointer per user per channel; search must filter results by what the user is allowed to see.

Trade-offs: sharding by workspace keeps a tenant's data together but creates hot shards for very large customers; message order within a channel comes from a server-assigned timestamp per channel.

Video and streaming

Design Zoom

Clarify: one-to-one and group video, screen sharing, chat and recording, with end-to-end latency ideally under about 150 milliseconds and meetings of up to hundreds of people.

Core design: a signaling service handles joining and the exchange of connection details; one-to-one calls can go peer to peer, with TURN relays for networks that block it; group calls go through media servers. Media travels over UDP with jitter buffers and error correction because a late packet is worth nothing.

Deep dive: the selective forwarding unit. An SFU forwards streams without decoding them, so it scales and adds little delay; an MCU mixes streams into one, which saves client bandwidth but costs heavy server CPU. Clients send several quality layers (simulcast), and the SFU forwards the layer each receiver's connection can take. Global meetings join the nearest region and cascade between SFUs.

Trade-offs: quality against latency; recording works as a server-side participant that writes streams to storage; end-to-end encryption limits what the server can do, such as recording or transcription.

Design YouTube

Clarify: upload, processing, playback, view counts and comments. Recommendations are usually a separate question. Uploads are a small share of traffic; playback and storage are the scale problem.

Core design: chunked, resumable uploads go to object storage; a transcoding pipeline splits each video into segments, transcodes them in parallel into several resolutions and codecs, and packages them for adaptive streaming (HLS or DASH); metadata lives in a database; a CDN serves the segments; the player switches bitrate as bandwidth changes.

Deep dive: the transcoding pipeline as a directed graph of tasks on a queue with workers, retries and idempotent steps; CDN strategy, with popular videos cached at the edge and the long tail served from regional caches or origin; and view counts, which are batched and aggregated in a stream rather than written one by one.

Trade-offs: storing every rendition costs storage, while transcoding rare renditions on demand costs latency; copyright checks run asynchronously after upload.

Design Netflix

Netflix differs from YouTube in ways interviewers like to probe: the catalog is curated rather than uploaded by users, every title is encoded in advance into many versions, and delivery runs through Netflix's own CDN appliances placed inside internet providers' networks and filled overnight with the titles they expect people to watch.

Core design: a cloud control plane handles browsing, playback authorization, licenses and recommendations; the data plane is the CDN. When you press play, the playback service checks your plan and device, returns a manifest and a ranked list of nearby CDN servers, and the client streams with adaptive bitrate.

Deep dive: the playback flow above, CDN prefill based on predicted popularity, and resilience: timeouts, circuit breakers and fallbacks so that if recommendations fail, the home page still renders with a default row. Personalized artwork and row ordering are a good extra if time allows.

Trade-offs: owning a CDN is expensive but gives control of quality and cost at peak; precomputed recommendations are cheap to serve but less fresh.

Notifications

Design a notification system

Clarify: which channels (iOS push, Android push, SMS, email, in-app), who sends (many internal services), user preferences and opt-outs, scheduling, templates and delivery tracking. Soft real-time is enough for most notifications, but one-time passcodes must be fast.

Core design: a notification API accepts events, validates them, checks preferences and rate limits, renders the template and puts a message on a queue per channel; channel workers call the providers (Apple's and Google's push services, an SMS gateway, an email service), record the result and retry failures with backoff; a device-token registry keeps push tokens current.

Deep dive: reliability (at-least-once delivery with an idempotency key per notification so retries never double-send, plus dead-letter queues), rate limiting per user and per provider, priority (passcodes jump ahead of marketing), and time zones for scheduled sends.

Trade-offs: exactly-once delivery across outside providers is not achievable, so design for safe retries; batch email to cut cost; keep analytics such as opens and clicks off the sending path.

The infrastructure questions that sit underneath all of these, such as rate limiters, caches and key-value stores, are walked through in system design building blocks; location, inventory and payments questions are in the marketplace, maps and payments walkthroughs.

Where CoPilot Interview fits

System design is a conversation, so the fastest way to improve is to say a design out loud and hear where it wobbles. CoPilot Interview is an AI interview assistant whose free AI mock interview can run a feed, chat or video design question against your résumé and the job description, read it aloud, score your spoken answer out of ten and show a model answer. The free plan gives 15 minutes a day of live help in sessions of up to 15 minutes, with AI mock interviews included. For the live round itself, follow your employer's rules: many companies now state their policy on AI tools in the invitation, and design rounds are where interviewers most want to hear your own reasoning.

Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly.

Frequently asked questions

Which of these system design questions come up most often?

A news feed or Twitter-style timeline and a chat system are among the most common at large tech companies, and a notification system is a frequent mid-level question. Video questions such as YouTube or Zoom appear more for media and infrastructure teams. The decisions repeat across all of them, so learn the decisions rather than the brand names.

How long should each part take in a 45-minute round?

About five minutes on requirements, two on estimates, ten on the API, data model and high-level design, fifteen to twenty on the deep dive and five on trade-offs. Interviewers mark candidates down most often for spending too long on requirements and never reaching the deep dive.

Do I need to name specific technologies?

Naming a category and the reason matters more than the product: say a wide-column store because writes are append-heavy and reads are by time range, then name an example if you know it well. Naming a technology you cannot defend invites a follow-up you will lose.

Should I memorize these designs?

No. Interviewers change one requirement to see whether you can adapt, for example by making the chat app end-to-end encrypted or the feed ranked. Learn why each choice was made so you can change it under pressure.

Where are the old single-question pages?

Each of the ten walkthroughs that used to be a separate page now lives in a section of this page, and the old addresses redirect to the matching section.