Bird
Raised Fist0

Netflix - Personalization, Adaptive Streaming, Global CDN Architecture

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Netflix - Personalization, Adaptive Streaming, Global CDN Architecture
Design a scalable, low-latency, global video streaming platform with personalized recommendations and adaptive bitrate streaming
hardVideo and Media StreamingFreq: high
Prerequisites:DNSHTTP
⚙️
Functional Requirements
  • Personalized video recommendations based on user watch history, ratings, and preferences
  • Adaptive bitrate streaming to dynamically adjust video quality based on client bandwidth and device capabilities
  • Global Content Delivery Network (CDN) to cache and deliver video content with low latency worldwide
  • User profile management including watchlists, viewing history, and preferences
  • Real-time playback analytics collection for monitoring QoE and user engagement
  • Search and browse catalog with metadata filtering and sorting
📊
Non-Functional Requirements
  • Support 2 billion daily active users globally
  • 99.99% availability SLA for video playback and personalization APIs
  • End-to-end latency for video start under 2 seconds (P99)
  • Adaptive streaming bitrate switch latency under 500ms
  • Personalization API response time under 100ms (P99)
❓
Clarifying Questions to Ask
  • What is the expected peak concurrent user count and peak QPS for personalization and streaming?
  • What video formats and codecs must be supported for adaptive streaming?
  • Are there regional restrictions or geo-blocking requirements for content delivery?
  • What is the retention period for user watch history and analytics data?
  • Should personalization be real-time or batch processed?
  • What client platforms (mobile, TV, web) must be supported?
Out of Scope
✗ Content ingestion and transcoding pipeline design
✗ DRM and content protection mechanisms
✗ Billing and subscription management
✗ Social sharing and user-generated content
📌
Assumptions
  • 2 billion daily active users (DAU)
  • Each user generates 40 personalization events per day (watch, rating, search)
  • Average event size is 100 bytes
  • Average video watch session is 30 minutes with adaptive streaming chunks of 4 seconds
⚡
QPS Calculation
write qps2B users × 40 events/day ÷ 86400 sec/day ≈ 925,926 writes/sec
peak write qpsAssuming 3× peak factor: 925,926 × 3 ≈ 2.78M writes/sec
read qpsAssuming 10 reads per user per day for personalization API: 2B × 10 ÷ 86400 ≈ 231,481 reads/sec
peak read qpsAssuming 3× peak factor: 231,481 × 3 ≈ 694,444 reads/sec
💾
Storage Estimate
daily storage2B users × 40 events × 100 bytes = 8 TB/day
retention days30
total storage8 TB/day × 30 days = 240 TB
with replicationReplication factor 3 → 240 TB × 3 = 720 TB total storage
🖥️
Server Estimate
personalization api serversAssuming 1000 RPS per server → 694,444 peak reads ÷ 1000 = ~695 servers
streaming edge serversTo handle 10M concurrent streams at 3 Mbps, assuming 1 Gbps per server → 30 Tbps ÷ 1 Gbps = 30,000 edge servers globally
🏗️
Architecture Diagram
Architecture Diagram
           +----------------------+
           |      User Clients    |
           +----------+-----------+
                      | HTTP/HTTPS
                      v
           +----------+-----------+
           | Global DNS Load      |
           |      Balancer        |
           +----------+-----------+
                      |
          +-----------+------------+
          |                        |
 +--------v-------+        +-------v--------+
 | Personalization|        |   CDN Edge     |
 |    API Layer   |        |  (Adaptive     |
 +--------+-------+        |  Streaming)    |
          |                +-------+--------+
          |                        |
 +--------v--------+       +-------v--------+
 |  User Profile   |       |  Origin Storage |
 |   DB (Cassandra)|       |  (S3 + HDFS)    |
 +--------+--------+       +----------------+
          |
 +--------v--------+
 |  Event Ingestion|
 |  Kafka Cluster  |
 +--------+--------+
          |
 +--------v--------+
 |  Analytics DB   |
 |  (ClickHouse)   |
 +-----------------+
🧩
Components
Global DNS Load Balancer
Directs user requests to nearest regional CDN edge or personalization API endpoints
Why thisAWS Route 53 latency-based routing reduces DNS resolution latency globally
Why notTraditional round-robin DNS lacks geo-awareness causing higher latency and poor user experience
Personalization API Layer
Serves personalized recommendations and user profile data with low latency
Why thisStateless microservices deployed on Kubernetes with autoscaling handle 700K+ QPS with 100ms P99 latency
Why notMonolithic servers cannot scale horizontally to meet 2B DAU and low latency SLAs
User Profile DB (Apache Cassandra)
Stores user watch history, preferences, and personalization metadata
Why thisCassandra provides linear write scalability and tunable consistency for 2.78M writes/sec peak
Why notPostgreSQL requires complex manual sharding at this write scale; B-tree writes don't scale linearly
Kafka Cluster
Ingests real-time user events for personalization and analytics asynchronously
Why thisKafka supports high-throughput, durable, ordered event streaming with partitioning for 3M+ writes/sec
Why notRabbitMQ lacks horizontal scalability and throughput for billions of daily events
Analytics DB (ClickHouse)
Stores aggregated playback and user engagement metrics for real-time analytics
Why thisClickHouse columnar DB enables fast OLAP queries on petabytes of event data with sub-second latency
Why notElasticsearch is optimized for search, not large-scale analytical queries at this volume
CDN Edge Servers
Cache and deliver video chunks with adaptive bitrate streaming close to users
Why thisCustom CDN edge servers with HTTP/2 and HLS/DASH support reduce latency and bandwidth costs
Why notPublic CDNs like Cloudflare lack fine-grained control over adaptive streaming and global scale
Origin Storage (S3 + HDFS)
Stores master video files and encoded chunks for CDN origin fetch
Why thisS3 provides durable, scalable object storage; HDFS supports batch processing for transcoding outputs
Why notTraditional SAN/NAS storage cannot scale cost-effectively to petabytes of video data
🔄
Data Flow
1
User Clients → Global DNS Load Balancer
User requests video or personalization data
DNS routes to nearest CDN edge or personalization API endpoint based on latency

Practice

(1/5)
1. Without a heartbeat mechanism in client-side service discovery, what exact failure occurs when a service instance crashes?
medium
A. The service registry automatically removes the crashed instance preventing stale routing
B. Clients continue sending requests to the crashed instance until cache expires, causing request failures
C. Clients immediately detect failure and reroute requests to healthy instances
D. Clients switch to server-side discovery to avoid stale instance usage

Solution

  1. Step 1: Understand heartbeat role in client-side discovery

    Heartbeats keep registry updated; without them, registry cannot detect crashed instances.

  2. Step 2: Trace failure impact

    Without heartbeats, registry retains stale instances; clients cache stale data and send requests to dead instances causing failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Registry removes crashed instances only if heartbeats present [check]
Hint: No heartbeat -> registry unaware -> stale instances persist [check]
Common Mistakes:
2. At 10x scale, which component in a Kafka-like distributed message queue is most likely to fail first, and why?
hard
A. The Kafka brokers, because partition leaders become overloaded with write and replication traffic
B. The consumer clients, because they cannot keep up with increased message consumption rates
C. The ZooKeeper ensemble, due to coordination overhead and leader election delays under heavy load
D. The network switches, due to increased packet loss under high throughput

Solution

  1. Step 1: Identify bottlenecks at 10x scale

    Network switches (A) scale with hardware upgrades; ZooKeeper (C) handles coordination but is lightweight compared to brokers; consumers (D) can be scaled horizontally.

  2. Step 2: Kafka broker partition leader overload

    Partition leaders handle all writes and replication for their partitions; at 10x scale, leaders become hotspots causing CPU, disk, and network saturation, leading to failures.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Partition leaders overloaded -> broker failure first at scale [check]
Hint: Partition leaders handle all writes -> overload first at scale [check]
Common Mistakes:
3. At 10x scale, which component in a real-time chat system is most likely to fail first due to latency-throughput trade-offs, and why?
hard
A. The database, because it cannot handle the increased write volume
B. The message broker, because partition count cannot be increased beyond a fixed limit
C. The load balancer, because it cannot distribute traffic evenly at high scale
D. The chat servers, because WebSocket connections are stateful and cannot be resharded easily

Solution

  1. Step 1: Identify stateful bottlenecks

    Chat servers maintain WebSocket connections statefully, limiting horizontal scaling.

  2. Step 2: Compare other components

    Databases (A) can be sharded; brokers (C) can add partitions; load balancers (D) scale horizontally; chat servers (B) fail first due to sticky state and connection limits.

  3. Final Answer:

    Option D -> Option D

  4. Quick Check:

    Stateful WebSocket servers limit scaling more than other components [check]
Hint: Stateful WebSocket servers block scaling first at 10x load [check]
Common Mistakes:
4. At 10x scale, which component in a microservices architecture is most likely to become the first bottleneck, and why?
hard
A. The shared database, because it cannot be sharded easily without complex coordination
B. The individual microservices, because their stateful WebSocket connections limit horizontal scaling
C. The service discovery system, because it must track exponentially more services and instances
D. The API Gateway, because it handles all incoming requests and becomes a centralized choke point

Solution

  1. Step 1: Identify stateful components at risk

    Stateful microservices holding WebSocket connections cannot easily shard or move connections, limiting horizontal scaling.

  2. Step 2: Compare other components' scaling characteristics

    Shared DB and service discovery can be sharded or cached; API Gateway can be scaled horizontally with load balancers.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Stateful WebSocket connections limit microservices horizontal scaling [check]
Hint: Stateful WebSocket limits microservices scaling first [check]
Common Mistakes:
5. At 10x scale, which component in the Redlock system is most likely to fail first and why?
hard
A. Redis masters due to increased memory usage from many locks
B. Lock expiration timers due to clock drift causing inconsistent lock validity
C. Network links between clients and Redis masters due to increased lock request volume
D. Clients due to increased network latency causing lock acquisition timeouts

Solution

  1. Step 1: Identify bottleneck at 10x scale

    Increased lock requests increase network latency and contention on clients acquiring locks.

  2. Step 2: Analyze impact on lock acquisition

    Higher latency causes clients to miss lock acquisition timeouts, reducing throughput and increasing retries.

  3. Step 3: Compare other components

    Redis masters scale better with sharding; network links and timers less likely first failure.

  4. Final Answer:

    Option D -> Option D

  5. Quick Check:

    Clients hit network latency -> lock timeouts -> first failure at scale [check]
Hint: Clients face latency -> lock timeouts -> first failure at scale [check]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard