Requirements

Functional Requirements:

• Users can create account and manage profiles (upto 4 per account)
• Only subscribed users can access the platform
• Subscribed users can watch tv shows/movies avialable in their region
• Users can search for tv shows/movies
• Users watching progress is tracked and synced across multiple devices
• User can view their home feed

Non-Functional Requirements:

• Low latency for streaming videos (<100ms)
• Highly Available
• High read throughput ~2.5 trillion/day reads
• Strong consistency for subscription payments
• Content is geo-locked

Capacity Estimation

• ~300M subscribed users
• ~100M DAU
• Reads:
  • All DAU watches ~5 videos daily and one video view = many read requests with ABR streaming
    • On Avg, 1 video = 500 segments
    • Each segment = 1 read request
    • So per day ~500M x 500 = 250B /day reads
    • Per sec: 2.5 million req

API Design

-> Account APIs

POST /accounts

Get /accounts/{id}

-> User profile APIs

POST /user-profile

GET /user-profile/{id}

-> Subscribe

POST /subscribe

-> Request for content playback

GET /content/{id}

• Returns a manifest file
• Manifest contains
  • available resolution
  • ABR options
  • Urls for segments (CDN)
  • segments sequence order

-> Search

GET /search?q={query}

• Return content ids + metadata

-> Home feed

GET /feed

• Returns home feed

-> Progress tracking

POST /progress

req -

{

userId,

contentId,

duration_watched

}

• Updates user progress

GET /progress/{userid}/{contentId}

• returns last watched position

GET /progress/{userid}

• Returns list of half watched content

High-Level Design

API Gateway

Acts as the entry point for all client requests.

Responsibilities:

• Authentication (if required)
• Rate limiting - Applied using token bucket per IP to prevent fraudulent or bot views
• Request routing

Load Balancer

Distributes traffic across multiple instances of all services to improve scalability and availability.

CDN

• Caching layer, storing content data, eg:
  • Content segments
  • Manifest files
  • Thumbnails
  • etc public facing data
• If CDN cache miss -> fetch from object storage

Object Storage

• Stores content Videos into multiple qualities
• Stores manifest files, thumbnails etc

Content Service

Responsibilities

• Creates new content (Admin managed not user facing)
• Recieves content playback request
• Validates the request
  • Checks user is subscribed
  • Checks the requested content is available in user region
• Returns back content manifest file

Geo content service

• Checks and returns if the content requested is available in user reqion or not.
• Checks using The ContentGeoPolicy table, which is source of truth, but is also cached in redis for faster reads

Feed Service

• Returns the user's home feed
• Fetch the following
  • Recommendation conetnt cache (user specific
  • Continue watching cache (user specific)
  • Trending cache (global)
• Pass the ids fetched to Rank service -> light ranking here, as ids in cache are already ranked.
• Check last updated time for the feed table in Db,
  • If last upadtged > 1 hr, update the db feed as well
• DB feed acts as a fall back when cache miss, or redis crahses

Progress Service

• Updated the user progress
• Emits progress updated event

Recommendation Service

Responsibilties

• Consumes ProgressUpdated Event
• The event procesing does the following
  • Update user preference i.e. update the genre scores and language scores,
• Also runs a daily background job to update the recommendation cache
• And an hourly job to update the continue watching cachee

Search Service

• receieves a serach query
• Parses the query and normalizes it
• Queries inverted index -> gets back video ids from it
• Merges and Passes the video ids to rank service -> gets back ranked ids
• For those ids fetches the metadata and returns response

Rank Service

• Ranks and returns teh video ids it recieves
• The ranking is based on analytics like:
  • Engagement
  • Ratings
  • Content popularity
  • Recency
• Scoring formula:

User Service

• Creates/updates account
• Manages user profiles

Subscription Service

• Recieves a subscription request
• Creates a subscription record in SQL
• Passes along to the payment gateway for payment
• If payment succeeds but downstream actions failed, a compensating refund is issued\
• After successfuly payment, updates the subscrption status

Redis

• Cahcing layer not source of truth
• Content Metadata
  • used to store content metadata for quick and fast response for apis like Get Video, Search queries
  • We do lazy loading
  • TTL is short lived ~1hr
• Feed info
  • Stores recommendations, contineu watching, tredning content ids what feed services use

PostreSQL + Casandra

• Primary persistent storage
• PostrSQL -> user, furutre entities like channels, ChannleSubscribers etc
• NoSQL -> Video, VideoMetadata, VideoReaction, VideoUpload etc

Database Design

We use a hybrid SQL (PostgreSQL) + NoSQL (Cassandra) architecture.

• SQL is used for strongly consistent relational data like Accouts, User Profiles, Subscriptions where relationships and transactions matter.
• NoSQL (Cassandra) is used for high-scale data like Content, UserContentProgress, User Prefences, ContentGeoPolicy, due to its horizontal scalability and high write throughput.

Data Models

SQL:

Account

Id (partition key)

email

passwordhash

UserProfile

Id (partition key)

accountId

name

language

region

Subscription

id

accountId (partition key)

plan

status

renewaldate

NoSQL

Content

id (partition key)

title

genre

description

rating

duration

manifestUrl

ContentGeoPolicy

Id

contentId (partition key)

Type - Allowed/Blocked

Regions

UserContentProgress

Id

userId (partition key)

contentid

durationWatched

last_position

UserPrefrences

userId (partition key)

genre_scores

last_updated

UserFeed (Fallback feed DB)

id

userId (partition key)

contentIds[]

updateAt

Search System

We use a distributed inverted index, where:

• keyword → list of content_ids
• used to support fast search queries

Partitioning Strategy

• Most NoSQL tables are partitioned by cotnetnId or userId to support fast reads.
• This ensures even distribution and aligns with primary access patterns (content playback, metadata fetch, user prefrences, progress).

Detailed Component Design

We will now deep dive into the following topics:

Adaptive Bitrate Streaming

ABR is needed in system like this, because we dont want to return the entire video content when user requests to watch the video, that is not efficent and takes a very long time when videos are very large. Instead we implement ABR using HLS/DASH:

How it works

• User request to watch the content
• GET /content/cotentId triggers
• The API returns back a manifest url
• Client fetches the manifest file from the url. The file contains:
  • Video segments URL (CDN)
  • Segment sequences
  • Available resolution
  • Other ABR options like, segment lengths, 10sec, 20sec etc
• Client uses the video segment url and fetches the content of the segment from CDN that user is currently watching as well the current quality user has selected, for eg: if user is at 0 sec, it fetches the first segment and starts playing
• As user continues to watch, the client continuosly polls CDN to retrieve the next segment, so if user is at 1:10 min, it will poll and fetch the video segments containing 1:20 to 1:30 content.
• Even if user peeks ahead of video, the cleint will poll CDN to fetch the video segement of taht partitucal minute and play the video.

-> Geo Locked content

• This is the most critical use case of Netflix, because for different productions, studios netflix have rights for certain regions only.
• To solve this we use and store a ContentGeoPolicy tablel
• This table is stores info of where content is available.
• When user requests to watch a content, this table determines whether the user region has the availability.

-> How do we determine user region and ensure proper security of no unauthorized access of content

• There are cpuple ways to determine user region

User IP Geolocation

• Every request hits CDN/API Gateway
• There we detect IP, we can map IP to region using geo services provided by cloud

User profile region

• user table have region stored set up at signup
• Not accurate, but is stable

We usually combine this, so formula is

if IP == user region from table

use it

else

apply rules:

travel execptions

subscription rights

Feed Service

• Feed service fetches user home feed.
• The feed service acts as an aggregator of different metrics:
  • Recoomendations
  • Continue watching
  • Trending
  • New releases
• These are all cached at Redis
• Recommendations and continue watching:
  • Recommendation service runs a prediocally background job that generates this
  • For recommendations:
    • The job fetches user preferences
    • For the strong scores, fetches the relevant content
    • Ranks the content using the score
    • Updates the cacehe with newly generated recommendation
  • For Continue watching
    • The job fetches user progress table
    • Checks recently watched content and whose progress is <95%
    • Again rankls them using the score
    • Updates the cache
• Trending and New releases -> managed globally, cached globally
  • Another background job runs daily and updates these
• In redis, we store all of this as a sorted set by score, timestamp
• Feed service will fetch these, merge all of the, do very light ranking
• Return back the feed

-> How do we sync user progress acorss multiple device?

• The user progress is synced via event processing
• When user start waching video, every second, the progress is batched locally, and every 10 sec the client calls the API to update the progress
• The API -> POSt /progress
• the progress service processes it and emits an progress updated event
• The event is then consumed for downstream updates for feed
• So now when user log ins with other device, theri progress is tracked, and a call to get the progress is made
• Get progress API returns back the last watched/last postion it stored from the first device it recieved.

Scaling strategies

• Add multiple instances for hot services like feed service, progress service, recommendation service
• Apply sharding for tables like UserPrefences, UserProgress

Failure handling:

Kafka failures

• retry with exponential backoff
• DLQ for poison messages
• replay from offsets

Subcription service crash

• issue compenstaion request to issue refund for successful payment

Redis failure

• rebuild from: DB -> feed table/content table
• cache is disposable