---

1-Hour Interview Roadmap

Time	Topic
0 – 5 min	Requirements clarification
5 – 10 min	Capacity estimation
10 – 18 min	High-level architecture + microservices
18 – 28 min	Video ingestion + encoding pipeline
28 – 38 min	Open Connect CDN — Netflix's custom delivery network
38 – 46 min	Database design + caching
46 – 54 min	Recommendation engine + search
54 – 60 min	Resilience (Chaos Engineering) + trade-offs

---

What Are We Building?

A global video-on-demand (VOD) streaming platform where:

• Subscribers watch licensed and original movies and TV shows
• Content is available in multiple languages and subtitle tracks
• Playback is smooth with adaptive quality based on network speed
• Every user gets a personalized home screen with ranked recommendations
• The platform stays available even when parts of infrastructure fail

Scale reference: Netflix has 270 million subscribers across 190 countries, streams ~15 petabytes of video per day, serves content from 1,000+ ISP locations globally, and delivers over 700,000 hours of video per minute at peak.

Key difference from YouTube: Netflix handles a curated, fixed catalog of licensed content (not user-generated uploads), uses its own globally deployed Open Connect CDN, and invests heavily in resilience engineering (Chaos Engineering, Circuit Breakers) to maintain 99.99% availability.

---

Step 1 — Requirements

Functional Requirements

#	Requirement
1	Users can browse and search the catalog of movies and TV shows
2	Users can stream videos seamlessly with adaptive quality (240p to 4K HDR)
3	Users receive personalized recommendations on the home screen
4	Videos include multiple audio tracks, subtitles, and dubbed versions
5	Users can create multiple profiles per account (up to 5)
6	Users can download content for offline viewing
7	Playback resumes where the user left off across devices
8	New content is published and available for streaming globally within hours

Non-Functional Requirements

#	Requirement
1	Video playback starts within 2 seconds on any device
2	No buffering on 5 Mbps+ connections — adaptive bitrate handles lower speeds
3	High availability — 99.99% uptime (< 52 min downtime/year)
4	Strong consistency for billing and profile data
5	Eventual consistency acceptable for viewing history and recommendations
6	Content must be protected with DRM (Widevine, FairPlay, PlayReady)
7	Platform must withstand AWS region outages — multi-region failover
8	System must tolerate random service failures gracefully (Chaos Engineering)

Out of Scope

• Live events streaming
• Payment and billing processing
• Content licensing and rights management
• Content moderation
• Mobile app UI / player implementation

---

Step 2 — Capacity Estimation

Assumptions

Metric	Value
Total subscribers	270 million
Daily Active Users (DAU)	100 million
Average stream duration per session	90 minutes
Concurrent streams at peak	15 million
Average bitrate (adaptive avg)	5 Mbps
Total catalog size	40,000 titles
Average encoded size per title	300 GB (all resolutions + languages)
New titles added per month	~1,500

Bandwidth at Peak

15 million concurrent streams × 5 Mbps = 75 Tbps peak outbound bandwidth

Netflix = ~15% of all downstream internet traffic during peak hours (North America)

Storage for Content Library

40,000 titles × 300 GB = 12 PB total encoded video storage

New additions: 1,500/month × 300 GB = ~450 TB/month

CDN Cache Sizing

Netflix's catalog has a Pareto distribution:
  Top 10% of titles = ~90% of all streams
  Top 10% of 40K = 4,000 titles × 300 GB = 1.2 PB

A single Open Connect Appliance (OCA) holds 100–200 TB
→ ~6–12 OCA nodes fully cache the top 10% of content
→ Deployed at 1,000+ ISPs globally

Key Insight

Netflix is a content delivery optimization problem. The system must get video bytes from central storage to the viewer's screen as fast as possible. The answer is pre-positioning content at the edge (Open Connect) before users request it — not reacting to demand.

---

Step 3 — High-Level Architecture

flowchart TD
    Client[Client\nTV / Mobile / Web] --> DNS[AWS Route53\nGeoDNS]
    DNS --> AG[API Gateway\nZuul]
    AG --> AUTH[Auth Service\n+ DRM License]
    AG --> CAT[Catalog Service]
    AG --> PLAY[Playback Service]
    AG --> REC[Recommendation Service]
    AG --> SEARCH[Search Service]
    AG --> UPR[User Profile Service]

    PLAY -->|manifest URL| Client
    Client -->|video segments| OCA[Open Connect Appliance\nNearest ISP PoP]
    OCA -->|cache miss| S3[AWS S3\nContent Storage]

    CAT --> CASS[(Cassandra\nCatalog + Metadata)]
    UPR --> MYSQL[(MySQL\nUser Profiles)]
    REC --> EVL[(Kafka\nView Events)]
    EVL --> ML[ML Pipeline\nSpark + TensorFlow]
    ML --> RS[(Redis\nRec Cache)]

    AUTH --> EVT[Kafka\nAuth Events]

Core Architectural Principles

Principle	How Netflix Implements It
Microservices	1,000+ independent services, each owning its data
API Gateway	Zuul — all client traffic enters through one gateway
Service discovery	Eureka — services register and discover each other dynamically
Load balancing	Ribbon — client-side load balancing across service instances
Circuit breakers	Hystrix — isolate failures, fail fast, fallback gracefully
Event streaming	Kafka — decouple services via async events
Cloud infrastructure	AWS — multi-region deployment (us-east-1 primary + DR regions)
Content delivery	Open Connect — own CDN at ISP level
Resilience testing	Chaos Engineering — Simian Army, Chaos Monkey

---

Step 4 — Microservices Architecture

Why Microservices?

Netflix was one of the early pioneers of microservices. Their motivations:

• Independent deployment — a bug in the Recommendation Service should not take down playback
• Independent scaling — Playback Service needs 10× more capacity than the Catalog Service
• Technology freedom — each team chooses the right tool for their service
• Failure isolation — a failure in Search should not prevent video streaming

Key Services

flowchart LR
    AG[Zuul\nAPI Gateway] --> AUTH[Auth & DRM]
    AG --> CAT[Catalog Service\nTitles, episodes, metadata]
    AG --> PLAY[Playback Service\nManifest generation]
    AG --> UPR[User Profile\nProfiles, settings, history]
    AG --> REC[Recommendation\nPersonalized rows]
    AG --> SRCH[Search\nElasticsearch]
    AG --> BILL[Billing\nPayment history]
    AG --> NOTIF[Notification\nEmail, push]

    EUR[Eureka\nService Registry] -.->|register + discover| AUTH
    EUR -.-> CAT
    EUR -.-> PLAY
    EUR -.-> UPR

Zuul — API Gateway

Zuul is Netflix's open-source API Gateway. It handles:

Responsibility	Detail
Authentication	Validate JWT tokens before forwarding to downstream services
Rate limiting	Per-user, per-device request limits
Request routing	Route /api/catalog to Catalog Service, /api/play to Playback
A/B testing	Route % of traffic to experimental service versions
Canary deployments	Gradually shift traffic to new versions
Request logging	Central access logging for all API traffic

Eureka — Service Discovery

flowchart LR
    PS1["Playback Service Instance 1"]
    PS2["Playback Service Instance 2"]
    PS3["Playback Service Instance 3"]

    EUR["Eureka Server"]

    CAT["Catalog Service"]

    PS1 --> EUR
    PS2 --> EUR
    PS3 --> EUR

    CAT --> EUR
    EUR --> CAT

    CAT --> PS2

• Each service instance registers itself with Eureka on startup
• Eureka maintains a heartbeat-based registry — instances that stop responding are deregistered
• Consuming services use Ribbon (client-side load balancer) to pick an instance from the registry

Hystrix — Circuit Breaker

flowchart LR
    REC[Recommendation\nService] -->|call| PLAY[Playback\nService]
    PLAY -->|normal| REC

    PLAY -->|failures > threshold| CB{Circuit\nBreaker}
    CB -->|OPEN| FB[Fallback\nReturn popular titles\ninstead]
    CB -->|after timeout| HALF[Half-Open\nTry one request]
    HALF -->|success| CLOSED[Circuit Closed\nNormal operation]

If the Recommendation Service is slow or failing:

• Circuit opens after 50% error rate in a 10-second window
• All calls immediately return the fallback (e.g., show trending titles instead of personalized)
• After 5 seconds, one request is tried — if it succeeds, circuit closes

This prevents one slow service from cascading into a full system outage.

---

Step 5 — Video Ingestion and Encoding

The Problem

Netflix acquires a movie as a studio master file — typically a 4K 12-bit RAW file that can be 100–300 GB per title. Before a subscriber can watch it:

1. The raw file must be encoded into multiple bitrates and resolutions
2. It must be packaged for multiple streaming protocols (DASH, HLS)
3. It must be encrypted with multiple DRM systems (Widevine, FairPlay, PlayReady)
4. It must include multiple audio tracks (5.1 surround, stereo, Atmos)
5. It must be localized (dubbed audio, subtitle tracks in 30+ languages)
6. It must be distributed to 1,000+ Open Connect Appliances globally

Ingestion Pipeline

sequenceDiagram
    participant Studio
    participant IS as Intake Service
    participant S3 as AWS S3 (Raw)
    participant KF as Kafka
    participant ENC as Encoding Farm
    participant QC as Quality Control
    participant S3P as S3 (Processed)
    participant OCA as Open Connect

    Studio->>IS: Deliver master file (secure transfer)
    IS->>S3: Store raw master
    IS->>KF: Publish content.ingested event

    KF->>ENC: Trigger encoding jobs
    ENC->>S3: Download raw master
    ENC->>ENC: Encode 100+ versions\n(resolution × audio × language)
    ENC->>QC: Submit for quality check
    QC->>S3P: Store approved encodes
    S3P->>OCA: Pre-position on appliances\nnightly proactive push

What Gets Encoded — Per Title

Resolution tiers: 240p, 360p, 480p, 720p, 1080p, 1080p HDR, 4K, 4K HDR
Audio:            Stereo, 5.1 Surround, Dolby Atmos
Languages:        English + 30+ dubbed/subtitled tracks
DRM packaging:    Widevine (Android/Chrome) + FairPlay (iOS/Safari) + PlayReady (Windows)
Protocols:        DASH (most devices) + HLS (Apple devices)

Total per title: ~100–150 separate encoded files

Why This Scale?

40,000 titles × 150 files × avg 2 GB per file = ~12 PB total storage

Netflix's encoding farm processes millions of encoding jobs per day
Uses AWS EC2 Spot Instances for cost-effective batch encoding

Video Codec Evolution

Generation	Codec	Bitrate Saving vs Previous	Netflix Adoption
1st	H.264 (AVC)	—	2010–present (fallback)
2nd	H.265 (HEVC)	~40% lower	2016–present (HD/4K)
3rd	AV1	~30% lower than HEVC	2020–present (premium)

AV1 at 4K saves ~50% bandwidth vs H.264 — at 75 Tbps peak, this is enormous cost savings.

---

Step 6 — Open Connect CDN

What Is Open Connect?

Open Connect is Netflix's own content delivery network — not AWS CloudFront, not Akamai. Netflix builds and operates its own edge servers and deploys them inside ISP (Internet Service Provider) data centers around the world.

flowchart TD
    S3[AWS S3\nMaster Content\nUS-East-1] -->|nightly proactive push| OCA1[Open Connect\nComcast PoP NYC]
    S3 -->|proactive push| OCA2[Open Connect\nBT UK London]
    S3 -->|proactive push| OCA3[Open Connect\nJio India Mumbai]
    S3 -->|proactive push| OCA4[Open Connect\nSoftBank Japan]

    User_NYC[User NYC] -->|video stream| OCA1
    User_London[User London] -->|video stream| OCA2
    User_Mumbai[User Mumbai] -->|video stream| OCA3

How Open Connect Works

sequenceDiagram
    participant Client
    participant DNS as AWS Route53\nGeoDNS
    participant PLAY as Playback Service
    participant STEER as Open Connect\nSteering Service
    participant OCA as Open Connect\nAppliance (ISP)
    participant S3

    Client->>DNS: Resolve api.netflix.com
    DNS-->>Client: Nearest AWS region endpoint

    Client->>PLAY: GET /playback/{content_id}
    PLAY->>STEER: Which OCA for this client IP?
    STEER-->>PLAY: OCA endpoint at client's ISP

    PLAY-->>Client: Manifest URL pointing to OCA

    Client->>OCA: GET video segments
    OCA-->>Client: Serve from local cache

    Note over OCA,S3: Cache miss (rare): OCA fetches from S3

Open Connect Appliance (OCA)

Component	Detail
Hardware	Custom-built servers, not off-the-shelf
Storage	100–280 TB SSD/HDD per appliance
Capacity	Serves 10–40 Gbps of video traffic each
Deployment	Installed inside ISP data centers (free colocation)
Count	1,000+ ISP locations globally
Cache strategy	Proactive push (not reactive pull-through)

Proactive vs Reactive Caching

Strategy	How it works	Netflix's choice
Reactive (pull)	Cache on first request; cache miss hits origin	YouTube/most CDNs
Proactive (push)	Netflix predicts popular content and pushes it to OCAs before users ask	Netflix

Netflix uses viewing history and release schedules to pre-position content overnight:

Every night at low-traffic hours:
  1. ML model predicts which content will be popular in each region tomorrow
  2. Fill OCA appliances at each ISP with predicted top content
  3. By morning, popular movies are already cached at the ISP inside user's home network
  4. When user presses play → segment served from inside their ISP → sub-10ms latency

Why Build Your Own CDN?

Reason	Detail
Cost	At 15% of internet traffic, paying Akamai per-GB would be billions/year
Control	Netflix can optimize OCA hardware and software for video-only
Quality	Can guarantee performance SLAs — no sharing with other customers
ISP relationships	ISPs allow OCA deployment in their data centers for free (reduces peering costs for ISP)
Predictive push	Control over what gets pre-positioned — reactive CDNs cannot do this at scale

---

Step 7 — Playback Flow

What Happens When You Press Play

sequenceDiagram
    participant Client
    participant ZUUL as Zuul API Gateway
    participant AUTH as Auth Service
    participant PLAY as Playback Service
    participant STEER as OC Steering Service
    participant OCA as Open Connect Appliance

    Client->>ZUUL: GET /api/play/{content_id}
    ZUUL->>AUTH: Validate JWT + Subscription check
    AUTH-->>ZUUL: Valid subscription (Standard plan)
    ZUUL->>PLAY: Forward request

    PLAY->>PLAY: Select max resolution (Standard = 1080p)
    PLAY->>STEER: Get best OCA for client IP
    STEER-->>PLAY: oca-nyc-comcast.netflix.com

    PLAY-->>Client: Playback manifest + DRM URL + max resolution

    Client->>AUTH: Request DRM license
    AUTH-->>Client: Encrypted content key

    Client->>OCA: Download manifest (DASH)
    OCA-->>Client: Segment URLs

    loop Streaming
        Client->>OCA: Fetch video segment
        OCA-->>Client: Encrypted segment
        Client->>Client: Decrypt and render
    end

Adaptive Bitrate on Netflix

Netflix uses a proprietary ABR algorithm called BOLA (Buffer-Occupancy Based Lyapunov Algorithm) which is more sophisticated than simple bandwidth-based switching:

Decision factors:
  1. Current download speed (bandwidth estimation)
  2. Current playback buffer level (how much is buffered ahead)
  3. Predicted future bandwidth (based on historical patterns)
  4. Segment duration and size at each quality level

Goal: maximize quality while keeping buffer > 15 seconds

---

Step 8 — Database Design

Database Selection

Data	Database	Reason
Content catalog	Cassandra	Write-once, high read volume, distributed, no complex joins
User profiles & settings	MySQL (+ CockroachDB for global)	ACID, user data must be strongly consistent
Viewing history	Cassandra	Append-only, per-user time-series, very high volume
Subscriptions & billing	MySQL	ACID — financial data must be exact
Recommendations cache	Redis	Sub-ms reads, pre-computed per user
Search index	Elasticsearch	Full-text search, title/genre/actor queries
Playback state (resume)	Cassandra	Per-user, per-device, high write volume
Analytics & events	Kafka → S3 + Spark	Real-time event ingestion; batch analytics

Content Catalog Table (Cassandra)

Table: content

Partition key:  content_id    UUID

Columns:
  title             TEXT
  content_type      VARCHAR   (MOVIE | SERIES | DOCUMENTARY | SHORT)
  genres            SET<TEXT>
  cast              LIST<TEXT>
  directors         LIST<TEXT>
  release_year      INT
  rating            VARCHAR   (G | PG | PG-13 | R | TV-MA)
  available_in      SET<TEXT> (country codes)
  languages         SET<TEXT> (audio + subtitle)
  manifest_url      TEXT      (base CDN URL)
  thumbnail_url     TEXT
  duration_seconds  INT
  created_at        TIMESTAMP
  updated_at        TIMESTAMP

Viewing History Table (Cassandra)

Table: viewing_history

Partition key:  user_id        UUID
Clustering key: watched_at     TIMESTAMP DESC

Columns:
  content_id        UUID
  profile_id        UUID
  resume_position   INT       (seconds watched)
  watch_percent     FLOAT
  device_type       VARCHAR   (MOBILE | TV | BROWSER | TABLET)
  stream_quality    VARCHAR   (720p | 1080p | 4K)

PRIMARY KEY (user_id, watched_at)

Resume Playback Table (Cassandra)

Table: playback_state

Partition key:  user_id        UUID
Clustering key: content_id     UUID
                profile_id     UUID

Columns:
  resume_position   INT       (seconds)
  last_watched_at   TIMESTAMP
  device_id         UUID

PRIMARY KEY (user_id, content_id, profile_id)

When a user resumes on a different device, the latest resume_position is fetched — this is the "Continue Watching" feature.

---

Step 9 — Caching Strategy

Redis Cache Map

Cache	Key Pattern	TTL	Contents
User recommendations	recs:{user_id}:{profile_id}	1 hr	Pre-computed list of 40 content IDs per row type
Content metadata	content:{content_id}	1 hr	Title, thumbnail, synopsis, cast
User profile	user:{user_id}	30 min	Profile list, subscription plan, preferences
OC Steering result	steer:{ip_prefix}	30 min	Best OCA endpoint for this IP range
Trending content	trending:{region}	5 min	Top 50 content IDs by view volume in last 24h
Search autocomplete	suggest:{prefix}:{lang}	1 hr	Top completions for query prefix
DRM license	drm:{user_id}:{content_id}	Session	Cached license to avoid repeated license server calls

EVCache — Netflix's Distributed Cache

Netflix built EVCache on top of Memcached, deployed across multiple AWS availability zones:

flowchart LR
    App[Application\nService] -->|write| EVC[EVCache\nCluster AZ-1]
    App -->|write replicated| EVC2[EVCache\nCluster AZ-2]
    App -->|write replicated| EVC3[EVCache\nCluster AZ-3]
    App -->|read| EVC

• Writes replicated synchronously to all AZs
• Reads from local AZ — sub-millisecond
• If one AZ fails, reads automatically shift to another AZ
• This is how Netflix maintains recommendation and metadata serving during partial outages

---

Step 10 — Recommendation Engine

Why Recommendations Drive Netflix

Netflix reports that 80% of content watched comes from the recommendation system — not from searching. The home screen is the product.

Recommendation Architecture

flowchart TD
    VH[Viewing History\nLikes, Ratings\nSearch Queries\nWatch Time] --> KF[Kafka\nView Events Stream]

    KF --> OL[Online Layer\nReal-time feature updates]
    KF --> BL[Offline Layer\nBatch ML Training\nSpark + TensorFlow]

    BL -->|User-content affinity vectors| VS[(Embedding Store\nFAISS)]
    OL -->|Recent signals| RDB[(Redis\nContext Cache)]

    User -->|GET /home| RS[Recommendation Service]
    RS -->|Fetch user vector| VS
    VS -->|Candidate retrieval\n500 candidates| RANK[Ranking Service\nNeural Net]
    RANK -->|Context from| RDB
    RANK --> ROWS[Assemble home screen rows\nTop Picks, Trending, Because you watched...]
    ROWS --> RC[(EVCache\nHome Screen)]
    RC --> User

Home Screen Row Types

Row Type	Algorithm
Top Picks for [Name]	Collaborative filtering + content-based
Trending Now	Real-time viewing velocity in user's region
Because You Watched [Title]	Item-item similarity (embedding cosine distance)
New Releases	Recently added + personalized genre affinity
Watch It Again	Viewing history with completion < 90%
Popular on Netflix	Global viewing rank (recency-weighted)

Two-Stage Recommendation Pipeline

Stage	Method	Input	Output	Latency
Retrieval	Approximate nearest neighbor	All 40K titles	500 candidates	< 10ms
Ranking	Deep neural network (user + item + context features)	500 candidates	40 ranked titles	< 50ms

Retrieval — use pre-trained embeddings to find broadly relevant content fast.
Ranking — apply a personalized model that considers: time of day, device, recent watch, mood signals (genre of last 3 watches), season, new content boost.

Thumbnail Personalization

Netflix A/B tests different thumbnails for the same title per user:

User A (watches action movies) → shows explosion scene thumbnail
User B (watches for actors)    → shows close-up of lead actor
User C (watches horror)        → shows dark atmospheric thumbnail

The recommendation engine picks both what to show and how to show it.

---

Step 11 — Chaos Engineering and Resilience

What Is Chaos Engineering?

Netflix deliberately injects failures into production systems to discover weaknesses before they cause real outages. This practice was pioneered by Netflix and is called Chaos Engineering.

"The best way to avoid failure is to fail constantly." — Netflix Engineering

The Simian Army

Netflix built a suite of tools called the Simian Army to test resilience:

Tool	What It Does
Chaos Monkey	Randomly terminates EC2 instances in production during business hours
Chaos Gorilla	Simulates an entire AWS Availability Zone going offline
Chaos Kong	Simulates an entire AWS Region failing
Latency Monkey	Introduces artificial latency between services
Security Monkey	Scans for security vulnerabilities and misconfigurations
Conformity Monkey	Checks that services follow best practices

Chaos Monkey in Action

flowchart TD
    CM[Chaos Monkey\nruns during business hours] -->|randomly terminate| PS1[Playback Service\nInstance 3]
    PS1 -->|instance gone| EUR[Eureka removes\nInstance 3]
    EUR --> RIB[Ribbon picks\nInstance 1 or 2]
    RIB --> CONT[Streaming continues\nfor all users]

    CM -->|alert if| FAIL[Any user\naffected\nby termination]

If Chaos Monkey terminates an instance and users are impacted, a real bug has been discovered. The goal is to make the system so resilient that killing any single instance has zero user impact.

Resilience Patterns Netflix Uses

Pattern	Tool / Approach	Purpose
Circuit Breaker	Hystrix / Resilience4j	Stop calls to failing services; return fallback
Retry	Exponential backoff	Retry transient failures without overwhelming a degraded service
Bulkhead	Thread pool isolation	Isolate failures so one slow service can't drain thread pools
Timeout	Per-service timeouts	Fail fast rather than waiting for a slow response
Fallback	Hystrix fallback	Return cached / default data when a service is unavailable
Rate Limiting	Zuul + Token Bucket	Protect downstream services from being overwhelmed

Multi-Region Architecture

flowchart TD
    GLB[AWS Route53\nGeoDNS Failover] -->|normal| USE[US-East-1\nPrimary]
    GLB -->|failover| USW[US-West-2\nHot Standby]
    GLB -->|EU users| EUW[EU-West-1]

    USE -->|async replication| USW
    USE -->|async replication| EUW

    OCA_US[Open Connect\nUS ISPs] --- USE
    OCA_EU[Open Connect\nEU ISPs] --- EUW

Netflix maintains three AWS regions running simultaneously:

• US-East-1: Primary region, most traffic
• US-West-2: Hot standby — can take 100% of US traffic within minutes if US-East fails
• EU-West-1: Primary for European users

Chaos Kong Exercise

Netflix regularly runs Chaos Kong: deliberately route all traffic away from US-East-1 to US-West-2 to verify that failover actually works. This exercises the full disaster recovery path before it's ever needed in an emergency.

---

Step 12 — Failure Scenarios

Failure	Impact	Mitigation
Single OCA appliance down	Viewers at that ISP rerouted to next OCA	OC Steering detects failure; routes to next nearest appliance
AWS Availability Zone outage	Services in that AZ unavailable	Chaos Gorilla testing validates multi-AZ failover; traffic shifts in < 60s
AWS Region outage	All services in region down	Chaos Kong tested failover to hot standby region via Route53 DNS
Recommendation Service slow	Home screen slow to load	Hystrix circuit opens; return cached EVCache recommendations
Kafka lag	View events delayed	Kafka cluster RF=3; consumers auto-rebalance; eventual consistency acceptable
Cassandra node down	Some data unavailable	RF=3; coordinator retries on other nodes; lightweight transactions for critical data
DRM license service down	New streams cannot start (no license)	Cache license per session in EVCache; existing streams unaffected
OC Steering service down	Clients cannot get OCA endpoint	Fallback to default OCA region or S3 origin
EVCache (recommendation) down	Home screen falls back to generic content	Circuit breaker returns popular/trending titles as fallback

---

Final Architecture

flowchart TD
    Client[TV / Mobile / Web\nClients] --> R53[AWS Route53\nGeoDNS]
    R53 --> ZUUL[Zuul API Gateway]

    ZUUL --> AUTH[Auth + DRM Service]
    ZUUL --> CAT[Catalog Service]
    ZUUL --> PLAY[Playback + Steering Service]
    ZUUL --> REC[Recommendation Service]
    ZUUL --> SRCH[Search Service]
    ZUUL --> UPR[User Profile + Resume]

    EUR[Eureka\nService Registry] -.->|discover| ZUUL
    EUR -.-> PLAY
    EUR -.-> REC

    PLAY -->|segment URLs| OCA[Open Connect\n1000+ ISP PoPs]
    S3[AWS S3\nEncoded Content] -->|nightly push| OCA
    OCA -->|cache miss| S3

    CAT --> CASS[(Cassandra\nCatalog)]
    UPR --> MYSQL[(MySQL\nProfiles + Billing)]
    UPR --> CASS2[(Cassandra\nViewing History)]

    REC --> EVC[(EVCache\nRec Cache)]
    REC --> KF[Kafka\nView Events]
    KF --> ML[Spark + TF\nML Pipeline]
    ML --> FAISS[(FAISS\nEmbeddings)]

    SRCH --> ES[(Elasticsearch)]

    ZUUL --> HYS[Hystrix\nCircuit Breakers]

---

Technology Stack

Layer	Technology
API Gateway	Zuul (open-source, built by Netflix)
Service discovery	Eureka (open-source, built by Netflix)
Load balancing	Ribbon (client-side, built by Netflix)
Circuit breaker	Hystrix / Resilience4j (built by Netflix)
Cloud infrastructure	AWS (EC2, S3, RDS, Route53)
Content delivery	Open Connect (own CDN at ISP level)
Encoding	FFmpeg + custom pipeline on AWS Spot Instances
Video protocols	DASH (most devices) + HLS (Apple devices)
DRM	Widevine + FairPlay + PlayReady
Message streaming	Apache Kafka
Cache	EVCache (Memcached-based, built by Netflix)
Recommendation	TensorFlow + FAISS + Apache Spark
Catalog storage	Apache Cassandra
User data	MySQL (CockroachDB for global)
Search	Elasticsearch
Monitoring	Atlas (metrics, built by Netflix) + Kibana + Vizceral
Resilience testing	Simian Army — Chaos Monkey, Gorilla, Kong (built by Netflix)
Deployment	Spinnaker (CD pipeline, built by Netflix) + Kubernetes

---

Key Trade-Offs

Decision	Option A	Option B	Choice & Reason
CDN strategy	Third-party CDN (Akamai, Fastly)	Own CDN (Open Connect)	Open Connect — at 15% of internet traffic, economics and control favor own CDN
Cache strategy	Reactive pull-through	Proactive push (pre-position)	Proactive — predict demand, push overnight; no cold start on new releases
Streaming protocol	HLS only	DASH + HLS	Both — DASH for Android/Smart TVs; HLS required for Apple ecosystem
Video codec	H.264 (universal support)	AV1 (50% smaller)	Both — AV1 for premium devices; H.264 fallback for older devices
Service architecture	Monolith	Microservices	Microservices — independent scaling, deployment, and failure isolation
Resilience approach	Reactive (fix when broken)	Proactive (break it yourself)	Chaos Engineering — know your weaknesses before users discover them
Recommendation timing	Real-time per request	Pre-computed + EVCache	Pre-computed — ML inference at 270M users cannot be fully real-time
Consistency (viewing state)	Strong everywhere	Strong for billing; eventual for history	Mixed — billing is MySQL/ACID; history is Cassandra/eventual

---

Netflix vs YouTube — Key Design Differences

Dimension	Netflix	YouTube
Content model	Curated licensed + original (fixed catalog)	User-generated (millions of new videos/day)
Upload volume	~1,500 titles/month	720,000 videos/day
CDN model	Own CDN (Open Connect) at ISP level	Third-party CDN (Akamai, Fastly)
CDN strategy	Proactive push (predict and pre-position)	Reactive pull-through
DRM	Mandatory — Widevine + FairPlay + PlayReady	Optional (only for paid content)
Recommendation share	80% of viewing from recommendations	70% of viewing from recommendations
Resilience	Chaos Engineering, Simian Army	Standard multi-region failover
Live streaming	Not supported (VOD only)	YouTube Live supported
Key design challenge	Global low-latency delivery + resilience	Upload pipeline + fan-out at scale

---

Common Interview Mistakes

• ❌ Not explaining Open Connect — Netflix's CDN is fundamentally different from typical CDNs
• ❌ Treating Netflix like YouTube — they have very different content models and scale challenges
• ❌ Not mentioning proactive content pre-positioning — reactive caching is not enough at Netflix's scale
• ❌ Forgetting DRM — every stream Netflix serves is encrypted; this adds license service to the playback path
• ❌ No circuit breaker discussion — cascading failures are Netflix's primary availability threat
• ❌ Not explaining Chaos Engineering — it is a core differentiator of Netflix's architecture
• ❌ Monolithic database for user data and content catalog — different consistency needs require different databases
• ❌ No multi-region failover plan — Netflix has experienced and prepared for full AWS region outages
• ❌ Not mentioning Zuul and Eureka — Netflix's open-source contributions are directly relevant here
• ❌ Forgetting that 80% of views come from recommendations — it is the most important service

---

Interview Questions

1. How is Netflix's architecture different from YouTube's?
2. What is Open Connect and why did Netflix build its own CDN?
3. How does proactive content pre-positioning work?
4. What is Zuul and why does Netflix use an API Gateway?
5. What is Eureka? How does service discovery work in a microservices architecture?
6. What is a circuit breaker? Give an example of how Hystrix protects Netflix.
7. What is Chaos Engineering? What does Chaos Monkey do?
8. How does Netflix ensure it survives an entire AWS Region going down?
9. How does adaptive bitrate streaming work in Netflix's context?
10. How does DRM work — what happens between pressing Play and seeing video?
11. Why does Netflix use Cassandra for the content catalog?
12. How do recommendations work? What is the two-stage pipeline?
13. What is thumbnail personalization and how does it work?
14. How does EVCache help maintain availability when a service is slow?
15. How does Netflix handle the tradeoff between strong consistency (billing) and eventual consistency (viewing history)?

---

Summary

Concern	Solution
Video delivery	Open Connect CDN at ISP level — content served from inside user's network
Content pre-positioning	ML-predicted proactive push to OCAs overnight
Playback flow	Zuul → Playback Service → OC Steering → OCA → encrypted segment → DRM decrypt
Adaptive streaming	DASH + HLS with BOLA algorithm — buffer-aware quality selection
DRM protection	Widevine (Android) + FairPlay (iOS) + PlayReady (Windows) — all mandatory
Microservices	1,000+ services with Zuul, Eureka, Ribbon, Hystrix
Resilience	Chaos Engineering — Chaos Monkey, Gorilla, Kong running in production
Failure recovery	Circuit breakers + fallbacks + multi-region failover (Route53 GeoDNS)
Recommendations	Two-stage: FAISS embedding retrieval → neural net ranking → EVCache
View history	Cassandra — per-user time-series, eventual consistency acceptable
Billing / profiles	MySQL — ACID, strong consistency required
Multi-region	US-East-1 (primary) + US-West-2 (hot standby) + EU-West-1; Chaos Kong tested

The core principle: Netflix is a content delivery and resilience problem. Get video bytes to the viewer's ISP before they ask for it. Build every service to fail gracefully. Test failures in production before they become real outages.

---