Design Netflix's System Architecture

Design Netflix's streaming architecture with diagrams and a design doc.

Introduction

30 Second Summary

Every time you press play on Netflix, a massive distributed system kicks into action. Video bytes travel from servers embedded inside your internet provider's network, a recommendation engine picks what to show you next, and dozens of microservices coordinate seamlessly to deliver a buffer-free experience to 300+ million subscribers worldwide.

In this project, you will design Netflix's system architecture from scratch using the same structured methodology tested in staff-level system design interviews. You'll create professional architecture diagrams and a written design document covering requirements, capacity estimation, and component deep dives.

What You'll Build

A complete system design document and three architecture diagrams for Netflix's video streaming platform, built using Excalidraw and a structured design methodology.

By the end of this project, you'll have:

A high-level architecture diagram showing Netflix's three-layer design (edge, application, data) with core microservices and data stores.
A CDN and streaming pipeline diagram showing how video travels from origin servers to your screen through Netflix's Open Connect network.
A recommendation data flow diagram mapping the ML pipeline that drives over 80% of content watched on the platform.
A written design document with requirements, capacity estimation, and architectural decisions that demonstrates you can reason about large-scale distributed systems.
Secret Mission: Add a chaos engineering strategy section explaining how Netflix designs for failure with graceful degradation patterns.

Are there any prerequisites?

You should have a basic understanding of web applications, including the client-server model, APIs, and databases. No prior system design experience is needed. This project teaches you the methodology from the ground up.

Set Up Your Design Workspace

Before diving into Netflix's architecture, you need a workspace where you can sketch diagrams and write up your design decisions.

In this step, you'll open Excalidraw for diagramming and create a structured Markdown document for your system design notes.

In this step, get ready to:

Open Excalidraw for architecture diagrams.
Create your design document in a text editor.
Structure the document with standard system design sections.

Open Excalidraw in your browser

Excalidraw is a free, infinite-canvas whiteboard tool that runs entirely in your browser. No account or installation required.

Open a new browser tab.
Navigate to https://excalidraw.com.

You should see a blank white canvas with drawing tools along the top and left side.

Why Excalidraw for system design?

Excalidraw's hand-drawn sketch style mirrors what you'd draw on a whiteboard in an actual system design interview. It encourages quick iteration over pixel-perfect diagrams.

You'll keep this tab open throughout the project. Every time the project says "in Excalidraw," switch back to this tab.

Create your design document file

Your design document is a Markdown file where you'll capture requirements, capacity estimates, and architectural decisions. Think of it as the written companion to your diagrams.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Visual Studio Code and press Enter to open it.

Any text editor works

If you prefer a different editor (Sublime Text, Notepad++, or even TextEdit/Notepad), use that instead. If you don't have VS Code installed, download it free from https://code.visualstudio.com.

Open the integrated terminal by pressing Ctrl+` (Windows) or Cmd+` (macOS).
Move to your Desktop by running this command:

cd ~/Desktop

Create your project folder and move into it by running these commands:

mkdir netflix-system-design
cd netflix-system-design

Confirm the folder exists by running:

ls ~/Desktop | grep netflix

You should see netflix-system-design in the output.

Now open this folder in VS Code. Click File in the top menu bar.
Click Open Folder.
Navigate to your Desktop, select the netflix-system-design folder, then click Open.

Don't see the folder on your Desktop?

Make sure you ran cd ~/Desktop before mkdir. Without that first command, the folder was created in whatever directory your terminal started in (usually your home folder).

Run ls ~ to check if it ended up in your home directory instead. If so, move it with mv ~/netflix-system-design ~/Desktop/.

help me find my netflix-system-design folder

Set up the document structure

Every good system design follows a structured methodology. Your document mirrors the standard flow used in system design interviews: requirements, estimation, architecture, deep dives, and decisions.

In the VS Code Explorer sidebar, click the New File icon (the page icon with a + sign).
Name the file netflix-system-design.md and press Enter.
Paste the following section headers into the file:

# Netflix System Design

## 1. Requirements

## 2. Capacity Estimation

## 3. High-Level Architecture

## 4. Component Deep Dives

## 5. Key Design Decisions

What do these sections cover?

Requirements captures what the system must do (functional) and how well it must do it (non-functional).
Capacity Estimation sizes the system with back-of-the-envelope math so you know what scale you're designing for.
High-Level Architecture maps major components and how they communicate.
Component Deep Dives zooms into the most critical subsystems (CDN, recommendations).
Key Design Decisions explains why you chose each approach over alternatives.

Save the file with Cmd+S (macOS) or Ctrl+S (Windows).

You should see netflix-system-design.md listed in the Explorer sidebar with the section headers visible in the editor.

File not appearing in the sidebar?

Make sure you opened the netflix-system-design folder (not just a blank VS Code window). Check the Explorer sidebar title. It should say NETFLIX-SYSTEM-DESIGN at the top.

If it says No Folder Opened, go back to File > Open Folder and select your netflix-system-design folder from the Desktop.

help me get my netflix-system-design folder open in VS Code

✔️ Awesome, I've got everything!

Great. Make sure you've saved netflix-system-design.md and keep both your VS Code window and the Excalidraw browser tab open.

ⓧ I'd like to double check the full code

Here's what your netflix-system-design.md file should look like:

# Netflix System Design

## 1. Requirements

## 2. Capacity Estimation

## 3. High-Level Architecture

## 4. Component Deep Dives

## 5. Key Design Decisions

Your workspace is ready. Next up, you'll fill in the Requirements and Capacity Estimation sections with the numbers that define Netflix's scale.

Define Requirements and Estimate Scale

Your workspace is ready. Now it's time to fill in the substance of your design document, starting with the most critical step in any system design exercise: defining what the system actually needs to do and how much load it needs to handle.

In system design interviews, candidates who skip requirements gathering and jump straight to drawing boxes almost always produce a design that misses the point. Requirements and capacity estimation anchor every decision that follows.

In this step, get ready to:

Write functional requirements covering Netflix's core features.
Write non-functional requirements defining quality attributes.
Calculate capacity estimates for users, bandwidth, and storage.

Write functional requirements

Functional requirements describe what the system does from a user's perspective. These are the features a product manager would put on a roadmap.

In your text editor, find the ## 1. Requirements section in netflix-system-design.md.
Add the following functional requirements below that heading:

### Functional Requirements
- User authentication and profile management (up to 5 profiles per account)
- Video search and browse with personalized recommendations
- Adaptive bitrate video streaming across all device types
- Content upload and transcoding pipeline
- Watch history and "continue watching" across devices

What do these requirements cover?

Each requirement maps to a major subsystem you'll design later:

Auth and profiles means you'll need a user service and session management.
Search and recommendations means you'll need a personalization engine and a search index.
Adaptive bitrate streaming means the system must encode video at multiple quality levels and switch between them based on the viewer's network conditions.
Content upload and transcoding means you'll need an offline processing pipeline.
Watch history across devices means you'll need a distributed data store that syncs state.

Save netflix-system-design.md.
Confirm you can see the five bullet points under a ### Functional Requirements subheading.

Write non-functional requirements

Non-functional requirements define how the system performs, not what it does. These are the quality attributes that separate a toy prototype from a production system serving 300+ million people.

Below your functional requirements (still under ## 1. Requirements), add the following:

### Non-Functional Requirements
- Low latency video start (sub-2-second)
- 99.99% availability
- Support for 300+ million subscribers with 12-25 million peak concurrent streams
- Horizontal scalability
- Content protection via DRM

Why do these numbers matter?

99.99% availability means less than 53 minutes of downtime per year. That constraint eliminates any single-server architecture immediately.

Sub-2-second video start means the system must have content pre-positioned close to users. You can't stream from a single origin server across the globe and hit that target. This requirement will drive the entire CDN design in later steps.

DRM (Digital Rights Management) protects content from unauthorized copying. Netflix must satisfy studio licensing agreements, which require encrypted delivery and license-based playback.

Save netflix-system-design.md.
You should now see both a ### Functional Requirements and a ### Non-Functional Requirements subheading under your Requirements section.

Add capacity estimation

Capacity estimation translates your requirements into concrete numbers. Interviewers use this to test whether you can reason about scale before diving into architecture.

Find the ## 2. Capacity Estimation section in your document.
Add the following calculations below that heading:

- Total users: ~300 million
- Peak concurrency: ~5-10% = 15-30 million simultaneous streams
- Peak bandwidth: at average 5 Mbps per stream = 75-150 Tbps
- Storage: thousands of titles, each encoded at multiple bitrates/resolutions/codecs = petabytes of video content

How did we get these numbers?

Netflix has 300+ million paid subscribers. At peak viewing hours, roughly 5-10% are streaming simultaneously. That gives us 15-30 million concurrent streams.

Each stream averages around 5 Mbps (a mix of mobile at 1.5 Mbps and 4K TVs at 15+ Mbps). Multiply 30 million streams by 5 Mbps and you get 150 Tbps of peak bandwidth. That's more traffic than most countries' entire internet infrastructure.

Storage is measured in petabytes because each title is encoded at dozens of bitrate and resolution combinations across multiple codecs. A single movie might produce 50+ encoded versions.

Save netflix-system-design.md.
Scroll through your document. You should see content under both ## 1. Requirements and ## 2. Capacity Estimation, with the remaining three sections still empty.

Document looking messy?

Make sure you have a blank line between each section heading and the content below it. Markdown needs that blank line to render headings correctly.

If your bullet points aren't rendering as a list, check that each line starts with - (dash followed by a space).

Help me fix my markdown formatting in netflix-system-design.md.

✔️ Awesome, I've got everything!

Great. Double check you've saved your file before moving on.

ⓧ I'd like to double check the full code

Here's what your complete netflix-system-design.md should look like at this point:

# Netflix System Design

## 1. Requirements

### Functional Requirements
- User authentication and profile management (up to 5 profiles per account)
- Video search and browse with personalized recommendations
- Adaptive bitrate video streaming across all device types
- Content upload and transcoding pipeline
- Watch history and "continue watching" across devices

### Non-Functional Requirements
- Low latency video start (sub-2-second)
- 99.99% availability
- Support for 300+ million subscribers with 12-25 million peak concurrent streams
- Horizontal scalability
- Content protection via DRM

## 2. Capacity Estimation

- Total users: ~300 million
- Peak concurrency: ~5-10% = 15-30 million simultaneous streams
- Peak bandwidth: at average 5 Mbps per stream = 75-150 Tbps
- Storage: thousands of titles, each encoded at multiple bitrates/resolutions/codecs = petabytes of video content

## 3. High-Level Architecture

## 4. Component Deep Dives

## 5. Key Design Decisions

You now have a solid foundation. Your requirements tell you what to build, and your capacity numbers tell you the scale it needs to handle. Next up, you'll translate these constraints into a high-level architecture diagram in Excalidraw.

Design the High-Level Architecture Diagram

Your requirements and capacity numbers define what Netflix needs to handle. Now you'll design how it handles that scale.

Netflix's architecture splits into three distinct layers, each with different scaling and failure properties. In this step, you'll draw this three-layer architecture in Excalidraw, showing how client devices connect through the edge all the way down to the data stores.

In this step, get ready to:

Draw three horizontal swim lanes representing Netflix's edge, application, and data layers.
Add core microservices and their communication patterns to the application layer.
Add distributed databases and the caching strategy to the data layer.

Draw the three-layer swim lanes

Netflix separates its infrastructure into three layers that scale independently. The edge handles video delivery close to users, the application layer handles business logic, and the data layer stores everything persistently.

Switch back to Excalidraw in your browser.
Select the Rectangle tool from the toolbar at the top (or press R).
Draw three large horizontal rectangles stacked vertically, leaving space between them. These are your swim lanes.
Select the Text tool (or press T) and label each swim lane from top to bottom:
Top lane: Edge Layer (Open Connect CDN).
Middle lane: Application Layer (AWS).
Bottom lane: Data Layer (Distributed Databases).
On the left side of the canvas (outside the swim lanes), draw four small rectangles representing client devices. Label them Mobile, TV, Browser, and Console.
Use the Arrow tool (or press A) to draw arrows from each client device into the Edge Layer swim lane.

What is Open Connect?

Open Connect is Netflix's proprietary CDN with physical appliances installed inside ISP data centres globally. Netflix provides these servers to qualifying ISP partners at no charge.

This means when you stream a show, the video bytes travel from a server physically inside your internet provider's building. That's why Netflix can achieve sub-2-second start times.

Your canvas should now show four client devices on the left with arrows pointing into the top swim lane, and three clearly labeled horizontal lanes stacked vertically.

Swim lanes overlapping or hard to read?

Make each rectangle wide enough to fit several boxes inside it later. Leave vertical gaps between the lanes so the labels stay readable.

You can select all elements with Cmd+A (macOS) or Ctrl+A (Windows) and resize the group if you need more space.

Help me lay out my swim lanes in Excalidraw

Add microservices to the application layer

Netflix runs hundreds of microservices on AWS, but in a system design interview you only need to show the core ones. Each service handles a single responsibility and communicates over REST or gRPC.

Inside the Application Layer (AWS) swim lane, draw seven small rectangles (boxes) arranged in a row or grid. Label each one:
API Gateway (Zuul).
Service Discovery (Eureka).
Auth Service.
Playback Service.
Recommendation Engine.
Search Service (Elasticsearch).
Billing Service.
Position API Gateway (Zuul) at the top of the application layer, closest to the edge. This is the entry point for all client requests.
Draw arrows from the API Gateway down to each of the other services to show REST/gRPC communication.
Draw a horizontal box at the bottom of the application layer (between the services and the data layer below). Label it EVCache.

What do these services do?

API Gateway (Zuul) routes incoming requests to the right microservice and handles cross-cutting concerns like rate limiting.
Service Discovery (Eureka) is Netflix's REST-based service registry. Services register themselves here so other services can find them without hardcoded addresses.
EVCache is Netflix's distributed caching layer built on Memcached. It sits between the services and databases so most read requests never hit the database directly.

Why microservices instead of a monolith?

At Netflix's scale (300+ million subscribers, 12-25 million peak concurrent streams), different parts of the system need to scale independently. The playback service needs far more instances than the billing service.

Microservices also isolate failures. If the recommendation engine overloads, playback keeps working. A monolith would take everything down together.

Your application layer should now show the API Gateway at the top fanning out to six services below it, with the EVCache bar sitting at the bottom edge of the swim lane.

Running out of space in the application layer?

Arrange the services in a 2x3 grid instead of a single row. The layout doesn't need to be pixel-perfect. What matters is that the components and their connections are clear.

Help me fit all my microservices in the application layer

Add databases and label the caching strategy

Netflix uses different database technologies for different data patterns. The key insight is that a caching layer (EVCache) sits in front of all database reads, so the databases rarely take direct traffic.

Inside the Data Layer (Distributed Databases) swim lane, draw three boxes and label them:
Apache Cassandra with a subtitle user data, viewing history.
MySQL/RDS with a subtitle billing, account metadata.
S3 with a subtitle video assets, encoded content.
Draw arrows from the EVCache box down to each database.
Add a text label on the connection between the Application Layer and the Data Layer that reads: EVCache fronts all reads.
Save your diagram by pressing Cmd+S (macOS) or Ctrl+S (Windows). Excalidraw saves to your browser's local storage automatically, but this creates a downloadable .excalidraw file as a backup.

Why these specific databases?

Apache Cassandra prioritises availability over consistency. Perfect for viewing history where it's acceptable to show a slightly stale "continue watching" list rather than showing nothing.
MySQL/RDS handles transactional data like billing where consistency matters. You can't charge someone twice.
S3 stores the petabytes of encoded video content. It's object storage designed for massive static files.

Your completed diagram should show the full flow: client devices on the left connect to the Edge Layer, which connects down to the Application Layer with its microservices, which connects through EVCache to the Data Layer with three database types.

Make it interview-ready

In a real system design interview, you'd draw exactly this diagram in the first 5-10 minutes. The three-layer separation immediately shows your interviewer that you understand Netflix's architecture split: control plane on AWS, data plane on Open Connect.

Diagram feels too cluttered?

Use Excalidraw's colour options to give each swim lane a different background colour. Select a rectangle, then pick a fill colour from the left panel. This visually separates the layers without needing thick borders.

Help me clean up my architecture diagram

✔️ Awesome, I've got everything!

Great. Double check that your diagram has all three swim lanes labeled, seven microservice boxes in the application layer, EVCache between the layers, and three databases in the data layer.

ⓧ I'd like to double check the full diagram

Here's what your completed high-level architecture diagram should contain:

Three horizontal swim lanes (top to bottom): Edge Layer (Open Connect CDN), Application Layer (AWS), Data Layer (Distributed Databases).
Client devices on the left: Mobile, TV, Browser, Console with arrows into the Edge Layer.
Application layer boxes: API Gateway (Zuul), Service Discovery (Eureka), Auth Service, Playback Service, Recommendation Engine, Search Service (Elasticsearch), Billing Service.
Arrows from API Gateway to each service showing REST/gRPC communication.
EVCache bar at the bottom of the application layer.
Data layer boxes: Apache Cassandra (user data, viewing history), MySQL/RDS (billing, account metadata), S3 (video assets, encoded content).
Label between application and data layers: EVCache fronts all reads.

Your high-level architecture captures the "big picture" of how Netflix is structured. Next, you'll zoom into the most interesting part of this diagram: how video actually gets from Netflix's servers to your screen through the Open Connect CDN.

Design the CDN and Streaming Pipeline

Your high-level architecture diagram captures the three layers of Netflix's system. Now it's time to zoom into the most critical piece: how video actually gets from Netflix's servers to your screen.

Netflix separates content preparation (encoding and caching) from content playback (streaming to the viewer). This separation is the key to serving 300+ million subscribers without buffering.

In this step, get ready to:

Draw the offline content preparation pipeline (encoding and caching).
Draw the online playback pipeline (streaming to viewers).
Add Open Connect CDN details showing ISP-level caching.

Draw the offline content preparation pipeline

Netflix doesn't encode video on the fly when you press play. Every title is pre-processed and pushed to edge servers long before anyone watches it.

In Excalidraw, create a new blank canvas for your second diagram. You can open a new tab at excalidraw.com or use the same canvas and scroll to a fresh area.
Draw a vertical dividing line down the middle of the canvas.
Label the left side Offline Pipeline (Content Preparation) and the right side Online Pipeline (Playback).
On the left side, draw a chain of boxes connected by arrows in this order from top to bottom:

Raw Content (the original video file uploaded by the studio).
Transcoding (Cosmos) (Netflix's encoding pipeline that converts raw video into streamable formats).
Per-title/per-shot encoding with VMAF quality optimization (each scene gets its own bitrate allocation based on visual complexity).
Multiple codecs (H.264, AV1) at multiple bitrates (the same video encoded in different qualities and formats for different devices).
Package and store in S3 (Amazon's object storage holds the encoded files as the origin).
Fill pipeline pushes to Open Connect Appliances (OCAs) during off-peak hours.

What is per-title/per-shot encoding?

Traditional encoding applies the same bitrate to every scene. Netflix's approach analyzes each shot individually. A dark, static dialogue scene needs far fewer bits than an action sequence with fast motion and bright colors.

VMAF (Video Multimethod Assessment Fusion) is a perceptual quality metric that scores how good the video looks to a human eye. Netflix encodes until VMAF scores hit their quality target, using fewer bits for simple scenes and more for complex ones.

You should now see a top-to-bottom flow on the left side of your canvas showing the full journey from raw content to cached edge servers.

Draw the online playback pipeline

The offline pipeline prepares content in advance. The online pipeline handles what happens in real time when a subscriber presses play.

On the right side of your canvas, draw another chain of boxes connected by arrows from top to bottom:

Client requests playback (the viewer hits the play button on their device).
API Gateway authenticates (verifies the user has a valid subscription and DRM rights).
Playback Service generates device-specific manifest (a list of available codec, resolution, and bitrate options tailored to the viewer's device).
Steering Service selects nearest healthy OCA (picks the best edge server based on location, load, and health).
Client acquires DRM license (happens in parallel with fetching the first video segment).
Client streams from OCA with adaptive bitrate switching (quality adjusts up or down based on network conditions).

Below both pipelines, add a text label with this key insight: Control plane on AWS, data plane on Open Connect. Video bytes never leave Open Connect.

Why separate the control plane from the data plane?

The control plane (authentication, manifest generation, DRM licensing, recommendations) runs on AWS because these are small, logic-heavy requests that benefit from flexible cloud scaling.

The data plane (actual video bytes) runs on Open Connect because video delivery is bandwidth-heavy and latency-sensitive. Serving from servers physically inside your ISP's network eliminates internet backbone hops entirely.

Your right side should now show the full real-time playback flow from the moment a viewer presses play to the moment video appears on screen.

Add Open Connect CDN details

Open Connect is what makes Netflix's architecture unique. Instead of renting CDN capacity from a third party, Netflix places its own hardware inside ISP data centers worldwide.

Below or beside your main pipelines, draw 2-3 boxes labeled ISP Network. Inside each ISP box, draw a smaller box labeled OCA (Open Connect Appliance).
Draw a dashed arrow from the S3/origin box in your offline pipeline to the OCA boxes. Label this arrow nightly fill during off-peak.
Add a note near the OCA boxes: ~98% cache hit rate. This means only ~2% of requests ever go back to origin.
Add a second note about CDN selection: Client races multiple endpoints (DNS resolver, anycast, IX peering point, AWS fallback) and picks the fastest.

Why did Netflix build its own CDN?

At Netflix's scale (25+ Tbps peak traffic, 1000+ ISP partnerships), operating their own CDN gives them lower latency, more control over cache placement, and the ability to proactively position content before demand spikes.

This is NOT the right choice for most companies. Third-party CDNs like CloudFront or Akamai are correct for lower traffic volumes. Netflix's scale justifies the operational cost of managing physical hardware in ISP locations worldwide.

Save or export your completed CDN and streaming pipeline diagram. In Excalidraw, click the hamburger menu (three lines) in the top left, then select Export image to save a copy.

Your completed diagram should show two distinct flows side by side. The offline pipeline shows how content is prepared and cached. The online pipeline shows how playback happens in real time. The OCA detail shows where those cached bytes actually live.

Keep the hand-drawn style

Excalidraw's sketchy aesthetic mirrors how architects actually whiteboard in system design interviews. Don't worry about pixel-perfect alignment. Focus on making the data flow clear and the labels readable.

Your CDN and streaming pipeline diagram is complete. Next up, you'll design the recommendation system data flow, the engine that decides what 300+ million subscribers see on their homepage.

Design the Recommendation Data Flow

Your CDN diagram now shows exactly how video bytes travel from Netflix's origin to a viewer's screen. The next challenge is understanding how Netflix decides which content to show each user in the first place.

Netflix's recommendation system is responsible for over 80% of content watched on the platform. In this step, you'll diagram how user behavior flows through a multi-stage ML pipeline to produce those personalized homepages.

In this step, get ready to:

Draw input signals flowing into a Feature Store.
Design the two-stage recommendation pipeline (candidate generation and ranking).
Map the personalized homepage output and real-time feedback loop.

Draw the input signals and Feature Store

Netflix's recommendation engine doesn't just look at what you've watched. It ingests dozens of behavioral signals to understand your preferences at a granular level.

Switch to Excalidraw in your browser.
Create a new area on your canvas (or a new Excalidraw tab) for this third diagram.
On the left side of your canvas, draw 7 boxes arranged vertically, each representing an input signal:

Viewing History.
Completion Rates.
Browse Behavior (scroll speed, hover duration).
Device Preferences.
Time-of-Day Patterns.
Ratings.
Search Queries.

To the right of these signals, draw a large box labeled "Feature Store (Cassandra + EVCache)".
Draw arrows from each of the 7 input signal boxes into the Feature Store.

What is a Feature Store?

A Feature Store is a centralized repository that stores pre-computed data ("features") ready for machine learning models to consume. Netflix uses Cassandra for durable storage and EVCache for fast reads.

By computing features once and storing them here, Netflix avoids recalculating user preferences every time someone opens the app.

Your diagram should now show 7 input signals on the left with arrows converging into a single Feature Store box on the right.

Design the two-stage recommendation pipeline

Netflix's catalog contains thousands of titles. Scoring every single title with a complex model for every user would be computationally impossible. The solution is a two-stage pipeline that progressively narrows down the options.

To the right of your Feature Store, draw a box labeled "Stage 1: Candidate Generation".
Draw an arrow from the Feature Store into this box.
Inside or below this box, add a note: "Collaborative filtering + embedding similarity. Narrows full catalog to hundreds of candidates. Optimizes for recall."

Why two stages instead of one?

Stage 1 is a lightweight "net" that catches anything potentially relevant. It uses simpler models (collaborative filtering and embedding similarity) to whittle thousands of titles down to a few hundred. Speed matters here because it runs across the entire catalog.

Stage 2 is a precision scalpel. It applies expensive deep learning models to rank only the few hundred survivors. This split lets Netflix get both broad coverage and fine-grained personalization without melting their GPUs.

To the right of Candidate Generation, draw a second box labeled "Stage 2: Ranking".
Draw an arrow from Stage 1 into Stage 2.
Add a note to Stage 2: "Deep learning models predicting: click-through rate, watch time, completion rate, satisfaction."
To the right of Stage 2, draw a smaller box labeled "Personalized Artwork Selection".
Draw an arrow from Stage 2 into Personalized Artwork Selection.

What is personalized artwork selection?

Netflix doesn't just pick which titles to show you. It also picks which thumbnail image to display for each title. If you watch a lot of comedies, you might see a funny scene as the thumbnail. If you prefer romance, you'll see a different frame from the same show.

You should now see a clear left-to-right flow: Feature Store, then Stage 1 Candidate Generation, then Stage 2 Ranking, then Personalized Artwork Selection.

Add the output and real-time event processing layer

The pipeline's output is what Netflix calls the "Lolomo." This is the personalized homepage every user sees. The system also needs a feedback loop so that new viewing behavior continuously improves future recommendations.

To the right of Personalized Artwork Selection, draw a box labeled "Lolomo (List of Lists of Movies) - Homepage Output".
Draw an arrow from Personalized Artwork Selection into the Lolomo box.
Add a text note near the Lolomo box: "Personalization drives 80%+ of content watched on Netflix."

Below your main pipeline (or along the bottom of the diagram), draw two boxes side by side: "Apache Kafka" and "Apache Spark".
Label these together as "Real-Time Event Processing Layer".
Draw an arrow from the Lolomo box (representing user interactions with the homepage) down into Kafka.
Draw an arrow from Kafka to Spark (stream processing).
Draw an arrow from Spark back up into the Feature Store, completing the feedback loop.

Why does the feedback loop matter?

Every time a user scrolls past a title, clicks on something, or abandons a video mid-watch, that signal flows through Kafka into Spark for real-time processing. Spark updates the Feature Store so the next time the user opens Netflix, the recommendations are already adjusted.

This is what makes the system feel "alive." Watch one horror movie tonight and your homepage subtly shifts by tomorrow morning.

Review your complete diagram to confirm it shows the full cycle: input signals on the left, Feature Store, two-stage pipeline, Lolomo output on the right, and the Kafka/Spark feedback loop connecting the output back to the Feature Store.
Save or export your diagram (click the hamburger menu in Excalidraw, then **Save to disk** or **Export image**).

Label your arrows

Adding short labels to your arrows ("user signals", "candidates", "ranked titles", "events") makes the diagram readable at a glance. In a real interview, labeled arrows show the interviewer you understand what data flows between components.

Your third diagram is complete. You should see the full recommendation data flow from raw user behavior all the way through to a personalized homepage, with real-time event processing closing the loop.

Your three architecture diagrams are now complete. Next up, you'll pull everything together by documenting the key design decisions that make Netflix's architecture work at scale.

Document Key Design Decisions

Your three diagrams now capture Netflix's architecture visually. The final piece is explaining why Netflix made these architectural choices.

In a real system design interview, the diagrams show you can think spatially. The written decisions show you can reason about trade-offs. In this step, you'll complete your design document by writing the three most important architectural decisions Netflix made.

In this step, get ready to:

Document the control plane vs data plane architectural split.
Explain the "design for failure" philosophy.
Justify the CDN strategy decision.

Link your diagrams to the design document

Before writing the key decisions, your document still has two empty sections (3 and 4) that correspond to the diagrams you already created. Adding brief references here keeps the document navigable.

In netflix-system-design.md, find the empty ## 3. High-Level Architecture section and add the following line beneath it:

See Excalidraw Diagram 1 (three-layer: Edge/Application/Data).

Under the empty ## 4. Component Deep Dives section, add this line:

See Excalidraw Diagram 2 (CDN and Streaming Pipeline) and Diagram 3 (Recommendation Data Flow).

Why just a reference and not a full writeup?

In system design interviews, your diagrams ARE the architecture and deep-dive explanation. The written document complements them by capturing decisions and reasoning that diagrams can't convey. A one-line pointer keeps the document DRY (Don't Repeat Yourself) while still making sections 3 and 4 navigable.

Write about the control plane vs data plane split

The most defining architectural decision Netflix made is separating what controls video playback from what delivers video bytes. This is the control plane vs data plane split.

In netflix-system-design.md, scroll to the ## 5. Key Design Decisions section.
Add the following content below that heading:

### Control Plane vs Data Plane Split
Netflix separates the control plane (AWS: auth, manifests, DRM, recommendations) from the data plane (Open Connect: video byte delivery). This split works because the workloads have fundamentally different scaling, security, and failure properties.

What does this decision mean?

The control plane handles decisions: who is this user, what are they allowed to watch, which video quality should they get, what should we recommend next. These are logic-heavy, low-bandwidth operations that run on AWS.

The data plane handles delivery: streaming gigabytes of video to millions of screens simultaneously. This is bandwidth-heavy, latency-sensitive work that runs on Open Connect servers inside ISP networks. Separating them means each can scale, fail, and be secured independently.

Save netflix-system-design.md.
You should see a new ### Control Plane vs Data Plane Split subsection under Section 5 with two sentences explaining the split.

Document the design for failure philosophy

Netflix's second key decision is choosing degraded service over downtime. Instead of crashing when something fails, the system falls back to cached or simpler responses.

In netflix-system-design.md, add the following content directly below the control plane section you just wrote:

### Design for Failure Philosophy
- Stateless microservices enable replacing failed instances without data loss
- EVCache provides cached fallback when databases are slow
- Degraded experience over downtime (show cached recommendations rather than an error page)
- Regional data replication for failover

Why is this a design decision and not just best practice?

Most systems treat failures as exceptions to handle. Netflix treats failures as constants to design around. Making every microservice stateless (storing session data in EVCache instead of locally) costs more upfront but means any instance can die without losing user context.

The key insight: showing slightly stale recommendations is invisible to users. Showing an error page makes the news. Netflix deliberately chose "wrong but working" over "correct but broken."

Save netflix-system-design.md.
You should now have two subsections under Section 5. The new one lists four bullet points covering stateless services, caching, degraded experience, and replication.

Document the CDN strategy decision

Netflix's third decision is the most counterintuitive. They built their own CDN instead of paying for an existing one. This is a decision that only makes sense at extreme scale.

In netflix-system-design.md, add this final subsection below the design for failure section:

### CDN Strategy Decision
Netflix built Open Connect rather than using third-party CDNs (Akamai, CloudFront) because at their scale, self-operation gives them lower latency, more control over cache placement, and proactive content positioning. This is NOT the right choice for most companies, but is correct at Netflix's scale (25+ Tbps peak traffic, 1000+ ISP partnerships).

Why call out that this is scale-dependent?

In a system design interview, interviewers love to hear you qualify decisions. Saying "Netflix built their own CDN" shows knowledge. Saying "this only makes sense at 25+ Tbps because the operational cost of 1000+ ISP partnerships is only justified when you're delivering that much traffic" shows engineering judgment.

For most companies, a third-party CDN like CloudFront or Akamai is the correct choice. Netflix's scale makes the economics flip.

Save netflix-system-design.md.
Your Section 5 should now have three subsections: Control Plane vs Data Plane Split, Design for Failure Philosophy, and CDN Strategy Decision.

Document feeling disorganized?

Make sure each subsection uses a ### heading (three hashes) so it renders as a nested subsection under the ## Section 5 heading. If your text editor supports Markdown preview, use it to confirm the hierarchy looks correct.

Help me organize my system design document structure.

✔️ Awesome, I've got everything!

Great. Double check you've saved your file, then you're done with the design document.

ⓧ I'd like to double check the full code

Here is the complete netflix-system-design.md file for comparison:

# Netflix System Design

## 1. Requirements

### Functional Requirements
- User authentication and profile management (up to 5 profiles per account)
- Video search and browse with personalized recommendations
- Adaptive bitrate video streaming across all device types
- Content upload and transcoding pipeline
- Watch history and "continue watching" across devices

### Non-Functional Requirements
- Low latency video start (sub-2-second)
- 99.99% availability
- Support for 300+ million subscribers with 12-25 million peak concurrent streams
- Horizontal scalability
- Content protection via DRM

## 2. Capacity Estimation

- Total users: ~300 million
- Peak concurrency: ~5-10% = 15-30 million simultaneous streams
- Peak bandwidth: at average 5 Mbps per stream = 75-150 Tbps
- Storage: thousands of titles, each encoded at multiple bitrates/resolutions/codecs = petabytes of video content

## 3. High-Level Architecture

See Excalidraw Diagram 1 (three-layer: Edge/Application/Data).

## 4. Component Deep Dives

See Excalidraw Diagram 2 (CDN and Streaming Pipeline) and Diagram 3 (Recommendation Data Flow).

## 5. Key Design Decisions

### Control Plane vs Data Plane Split
Netflix separates the control plane (AWS: auth, manifests, DRM, recommendations) from the data plane (Open Connect: video byte delivery). This split works because the workloads have fundamentally different scaling, security, and failure properties.

### Design for Failure Philosophy
- Stateless microservices enable replacing failed instances without data loss
- EVCache provides cached fallback when databases are slow
- Degraded experience over downtime (show cached recommendations rather than an error page)
- Regional data replication for failover

### CDN Strategy Decision
Netflix built Open Connect rather than using third-party CDNs (Akamai, CloudFront) because at their scale, self-operation gives them lower latency, more control over cache placement, and proactive content positioning. This is NOT the right choice for most companies, but is correct at Netflix's scale (25+ Tbps peak traffic, 1000+ ISP partnerships).

Secret mission

Design the Chaos Engineering Strategy

Netflix's "design for failure" philosophy is legendary. They deliberately break their own systems in production to prove they can survive real outages. Add a chaos engineering section to your design document and annotate your architecture diagram with graceful degradation paths.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely locally and in your browser, so there are no ongoing costs.

Resources you used:

netflix-system-design.md design document (local file).
Three Excalidraw diagrams (stored in browser local storage).

Keep everything running

No action needed. Choose this if you're still actively working on your design or plan to refine your diagrams and document further.

Your netflix-system-design.md file stays wherever you saved it on your computer.
Your Excalidraw diagrams remain in your browser's local storage. You can reopen them at excalidraw.com anytime.
If you want to keep your diagrams permanently, export them as PNG or SVG files from Excalidraw before clearing your browser data.

Pause - I'll come back to this later

Save your work so you can pick it back up later without losing progress.

In Excalidraw, click the menu icon (hamburger menu) in the top left, then select Save to disk for each diagram. This downloads a .excalidraw file you can reopen later.
Make sure netflix-system-design.md is saved in your text editor.
Close your browser tabs and text editor. Your files will be waiting when you come back.

Delete - I don't want to use this again

Remove all project files and clear browser data to start completely fresh.

Delete your design document by running this command in the folder where you saved it:

macOS

rm netflix-system-design.md

Windows

del netflix-system-design.md

If you exported any .excalidraw or image files, delete those from your Downloads folder as well.
To clear Excalidraw's browser storage, open excalidraw.com, click the menu icon in the top left, then select Reset the canvas. This removes all diagrams stored in your browser.

Nice Work!

You just designed Netflix's system architecture from the ground up. You now have a portfolio-ready design document and three professional architecture diagrams that demonstrate you can reason about large-scale distributed systems.

You've learned how to:

Create professional architecture diagrams covering a three-layer design (edge, application, data), a CDN and streaming pipeline, and a recommendation data flow.
Write a structured system design document with requirements, capacity estimation, component deep dives, and key architectural decisions.
Apply a transferable system design methodology that works in interviews and real-world architecture: requirements, estimation, high-level design, deep dive, decisions.
Design a chaos engineering and fault tolerance strategy showing how Netflix maintains 99.99% uptime through graceful degradation patterns.

Ready to quiz yourself?