Netflix System Design — Explained Simply

A beginner-friendly walkthrough of how Netflix streams video to 250M+ people worldwide without (usually) buffering.

1. The Big Idea (Read This First)

Netflix is really two separate systems working together:

Analogy: Think of a restaurant. The AWS side is the waiter and menu (takes your order, remembers your preferences). Open Connect is the kitchen next door to your house (the food is already cooked and sitting close to you).

2. High-Level Architecture

                        ┌──────────────────────────┐
                        │        USER DEVICE       │
                        │ (TV, Phone, Laptop, Web) │
                        └────────────┬─────────────┘
                                     │
              ┌──────────────────────┴──────────────────────┐
              │                                             │
     (1) Browse / Login / Play click              (2) Stream the video
              │                                             │
              ▼                                             ▼
   ┌─────────────────────┐                      ┌──────────────────────┐
   │   AWS  (Control     │                      │  OPEN CONNECT (CDN)  │
   │   Plane)            │                      │  Servers inside your │
   │                     │  "Play this movie    │  ISP / nearby city   │
   │  • API Gateway      │   from THIS server"  │                      │
   │  • Microservices    │ ───────────────────▶ │  Stores video files  │
   │  • Databases        │                      │  (OCAs)              │
   │  • Recommendations  │                      └──────────────────────┘
   └─────────────────────┘

Flow in one line: You press play → AWS decides which nearby server is best → your device pulls video directly from that server.

3. What Happens When You Press "Play"? (Step by Step)

1. App opens → device calls Netflix API (hosted on AWS).
2. Authentication → checks your account, subscription, and device.
3. Home screen is built → recommendation services pick rows & thumbnails just for you.
4. You click Play → Playback service checks license/DRM rights and region availability.
5. Steering service picks the best Open Connect Appliance (OCA) based on location, network health, and server load.
6. Device receives a manifest (a list of available video qualities + OCA URLs).
7. Video streams in small chunks (a few seconds each) directly from the OCA.
8. Adaptive Bitrate (ABR) — if your Wi-Fi slows down, the player automatically switches to a lower quality chunk instead of buffering.
9. Telemetry (play, pause, buffering, quality) is sent back to Netflix for analytics.

4. Component Deep-Dive

4.1 Client Apps

• Native apps for iOS, Android, Smart TVs, consoles, and a web app.
• Contain the video player that handles adaptive streaming, DRM, subtitles, and audio tracks.

4.2 API Gateway (Front Door)

• Single entry point for all client requests.
• Netflix originally built Zuul (now evolved into Zuul 2, plus a federated GraphQL gateway).
• Does: routing, authentication, rate limiting, request filtering, load shedding.

4.3 Microservices (the heart of AWS side)

Netflix pioneered splitting one big app into hundreds of small services, each doing one job:

 ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
 │   User     │ │  Catalog   │ │  Search    │ │ Recommend  │
 │  Service   │ │  Service   │ │  Service   │ │  Service   │
 └────────────┘ └────────────┘ └────────────┘ └────────────┘
 ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
 │  Billing   │ │  Playback  │ │ Watchlist  │ │ Notification│
 │  Service   │ │  Service   │ │  Service   │ │  Service   │
 └────────────┘ └────────────┘ └────────────┘ └────────────┘

Why? Teams can deploy independently, scale only what's busy, and one failure doesn't take everything down.

Supporting tools:

• Eureka – service discovery ("where is the Billing service right now?").
• Client-side load balancing (originally Ribbon) – callers choose a healthy instance.
• Resilience patterns (circuit breakers, retries, timeouts — popularized by Hystrix, now replaced by adaptive concurrency limits).

4.4 Open Connect (Netflix's Own CDN) ⭐

This is the secret sauce.

• Netflix builds its own servers called OCAs (Open Connect Appliances).
• They are placed inside ISPs' data centers and at internet exchange points, for free.
• Popular content is pre-loaded at night (off-peak) so it's already sitting close to viewers.

Without CDN:   You ───────── (long distance) ───────── Netflix Data Center

With Open Connect:   You ── (short hop) ── OCA inside your ISP  ✅

Benefits:

• Lower latency and fewer buffering issues.
• ISPs save bandwidth on their backbone.
• Netflix controls the full delivery experience.

Fill strategy: Content is proactively pushed to OCAs based on predicted popularity per region — not fetched on demand like a typical cache.

4.5 Video Processing / Encoding Pipeline

When a studio gives Netflix a movie, it's a huge raw master file. Netflix converts it to work on every device and network speed:

 Raw Master File
       │
       ▼
 ┌──────────────┐   split into small chunks
 │  Chunking    │──────────────────────────┐
 └──────────────┘                          │
       ▼                                   ▼
 ┌──────────────────────────────────────────────┐
 │  Parallel encoding on thousands of AWS       │
 │  machines: many resolutions × bitrates ×     │
 │  codecs (H.264, HEVC, VP9, AV1)              │
 └──────────────────────────────────────────────┘
       │
       ▼
 ┌──────────────┐
 │ Quality check│  (automated, uses VMAF quality metric)
 └──────────────┘
       │
       ▼
 Distribute to Open Connect servers worldwide

Smart tricks:

• Per-title / per-shot encoding: An animated cartoon needs fewer bits than an action movie, so each title (and even each scene) gets its own optimal settings.
• Multiple audio tracks, subtitles, and artwork are also processed.
• DRM (Widevine, PlayReady, FairPlay) protects the content.

4.6 Adaptive Bitrate Streaming (ABR)

• Video is stored as many small segments (2–10 seconds) in multiple quality levels.
• Protocols: MPEG-DASH / HLS.
• The player measures your network speed and picks the best quality for each next segment.

Fast network:  [4K][4K][4K][4K]
Slow dip:      [4K][1080p][720p][480p]
Recovered:     [720p][1080p][4K]

4.7 Data Storage (Different Tools for Different Jobs)

Rule of thumb: No single database fits everything → use the right tool for each job (this is called polyglot persistence).

4.8 Recommendation System 🎯

Netflix says most of what people watch comes from recommendations.

Inputs:

• What you watched, how long, when, on what device
• Searches, ratings, thumbs up/down
• Behavior of similar users
• Content metadata (genre, cast, mood, language)

Techniques:

• Collaborative filtering
• Deep learning / embeddings
• Contextual bandits (to test which choice works best)
• Personalized artwork – the same show may show you a different thumbnail than your friend.

Pipeline:

 Offline (batch)  → Train models on huge data (Spark)   → Store results
 Nearline         → Update with recent activity         → Fast refresh
 Online (real-time)→ Re-rank results in milliseconds    → Your home page

4.9 Data & Event Pipeline

Every click, play, pause, and buffer event is recorded.

 Devices & Services → Kafka (event streaming) → Flink / Spark (processing)
                                                  │
                           ┌──────────────────────┼───────────────────┐
                           ▼                      ▼                   ▼
                     Data Lake (S3)        Real-time dashboards     ML training

Used for: recommendations, A/B tests, detecting playback problems, capacity planning, business reports.

4.10 Experimentation (A/B Testing)

Netflix constantly runs thousands of experiments: Does this thumbnail increase plays? Does this UI change help? Nothing major ships without data.

5. Resilience: Designing for Failure 💥

Netflix assumes things will break and builds around it.

Chaos Engineering 🐒

Netflix intentionally breaks its own systems in production to find weaknesses:

• Chaos Monkey – randomly kills servers.
• Chaos Kong – simulates losing an entire AWS region.
• Simian Army / FIT – more failure-injection tools.

If it can survive random failures on purpose, it can survive real ones.

6. Scalability Strategies

• Horizontal scaling: add more instances instead of bigger machines.
• Auto Scaling Groups: traffic spikes (e.g., Friday evening, new season drops) automatically add servers.
• Stateless services: any instance can handle any request.
• Caching everywhere: EVCache, CDN, client-side caches.
• Geo-distribution: serve users from the nearest region/OCA.
• Asynchronous processing: non-urgent work is queued instead of blocking the user.

7. DevOps & Observability

8. Security

• Authentication & authorization at the gateway (tokens, device identity)
• DRM to prevent piracy
• Encryption in transit (TLS) and at rest
• Account sharing / abuse detection via device & usage signals
• Zero-trust style internal service-to-service auth (mutual TLS)

9. Complete Architecture (One Diagram)

                          ┌─────────────────────────┐
                          │      USER DEVICES       │
                          └─────┬─────────────┬─────┘
                       API calls│             │Video chunks
                                ▼             ▼
                      ┌───────────────┐  ┌──────────────────┐
                      │  API Gateway  │  │  OPEN CONNECT    │
                      │ (Zuul/GraphQL)│  │  OCAs in ISPs    │
                      └──────┬────────┘  └────────▲─────────┘
                             │                    │ pre-fill
         ┌───────────────────┼───────────────┐    │ (nightly)
         ▼                   ▼               ▼    │
   ┌──────────┐       ┌────────────┐  ┌──────────┴─┐
   │ User/Auth│       │ Playback & │  │ Encoding & │
   │ Billing  │       │ Steering   │  │ Content    │
   │ Services │       │ Services   │  │ Pipeline   │
   └────┬─────┘       └─────┬──────┘  └──────┬─────┘
        │                   │                │
   ┌────┴───────────────────┴────────────────┴────┐
   │ Recommendation • Search • Catalog • Watchlist │
   └────┬────────────────────────────────────┬─────┘
        │                                    │
   ┌────▼─────┐  ┌──────────┐  ┌───────┐  ┌──▼────────┐
   │ EVCache  │  │Cassandra │  │ MySQL │  │ S3 / ES   │
   └──────────┘  └──────────┘  └───────┘  └───────────┘
        ▲
        │ events
   ┌────┴────────────────────────────────────────────┐
   │ Kafka → Flink/Spark → Data Lake → ML / Analytics│
   └─────────────────────────────────────────────────┘

10. Key Design Decisions & Trade-offs

11. Quick Interview Cheat-Sheet 📝

If asked "Design Netflix" in an interview, hit these points:

1. Requirements: upload/process videos, stream with low latency, search, recommendations, global scale.
2. Split control plane vs data plane.
3. Video pipeline: chunk → encode into many formats → store.
4. CDN is critical — push popular content to edge servers.
5. Adaptive bitrate streaming (HLS/DASH).
6. Microservices + API gateway.
7. Right database per use case (Cassandra, MySQL, cache, S3).
8. Recommendations via offline + online ML.
9. Resilience: multi-region, circuit breakers, chaos testing.
10. Observability & A/B testing.

12. Glossary

📌 Summary in 3 Lines

1. AWS microservices handle everything except video bytes (login, browse, recommendations, playback decisions).
2. Open Connect CDN delivers the actual video from servers placed right inside your ISP.
3. Resilience, data pipelines, and ML personalization tie it together so streaming feels instant, reliable, and tailored to you.

Note: Netflix's internal stack evolves constantly; some tools named here (e.g., Hystrix, Ribbon) have been replaced or deprecated in favor of newer internal solutions, but the architectural ideas remain the same.