Netflix System Design: Trade-offs
Contents
~8 min read
~8 min read
Consistency, Availability, Partition Tolerance — you get at most 2. Since network partitions always happen, the real choice is CP vs AP, service by service.
You cannot double-charge a user. You cannot allow a session with an invalid refresh token. These require strong consistency.
Resume position being 3 seconds stale is completely acceptable. QUORUM writes ensure durability; LOCAL_ONE reads trade freshness for speed.
Recommendation cache is pre-computed and 6 hours stale. On partition, serve stale rows from Redis. Never block the homepage for ML freshness.
Video MUST stream even if the manifest metadata is stale. Availability is the north star. CloudFront serves video segments from cache regardless of API state.
Per-stream Redis keys with 60s TTL allow brief overcounting (e.g., a crashed stream slot frees in 60s). A momentary extra stream is acceptable; availability of the play button is not.
OpenSearch is indexed asynchronously via Kafka. New content appears in search results within seconds of ContentPublished event — eventual consistency is the explicit design.
DynamoDB Global Tables replicates asynchronously (~1s lag). Stale catalog metadata is acceptable. Regional availability enforcement is done at CDN layer as a second check.
Interview Script
“I'll choose CP for Auth and Billing because incorrect billing is legal liability and invalid sessions are security vulnerabilities. Everything else is AP: watch history (30s stale resume is invisible), recommendations (6h stale rows beat a blank homepage), CDN (must stream even if manifest is stale).”
Why Netflix uses 5 different databases. Each wins on one dimension its competitors can't match at Netflix scale.
Push wins when read-time computation is too expensive. Pull wins when you need guaranteed freshness. Hybrid is the answer when both matter.
Recommendations
Homepage load
< 2ms (Redis read)
Up to 6 hours
200ms ML inference × 150M DAU homepage loads = unacceptable latency on critical path
Watch Progress
Resume playback
30s heartbeat lag
30 seconds max
Push (heartbeat) for writes, pull (Cassandra read) for resume. Two different latency requirements.
Search Index
Content search, autocomplete
< 2ms (Redis ZSET)
Seconds (new content)
Pull-on-query would require full DynamoDB scan per search. Push-to-index makes reads cheap.
CDN Cache
Video segment delivery
< 5ms (edge cache hit)
Up to 1 year (immutable segments)
Pull-from-origin = 100ms+ per segment × 15M viewers = impossible. Push-to-edge before demand = < 5ms.
Email Notifications
PaymentFailed, NewEpisode alerts
Seconds to minutes
N/A — event-driven
Pull would require polling — expensive and inefficient. Event-driven push via Kafka is the right model for notifications.
Netflix pioneered microservices at scale. Know both sides — interviewers will push back on your choice.
Benefits
Independent deployments
Netflix deploys 200+ times/day. Each service team ships on their own schedule without coordinating with other teams. A bug in the Notification Service doesn't require a full platform deploy to fix.
Fault isolation
Recommendation Service can be down without Streaming Service failing. Circuit breakers ensure cascading failures don't propagate. With a monolith, any crash kills everything.
Technology heterogeneity
Recommendation Service uses Python + SageMaker. Auth Service uses Java. CDN logic uses Go. Each service uses the best tool for its job, not the lowest common denominator.
Team autonomy (Conway's Law)
Architecture mirrors org structure. The team that owns Auth also owns its database, deployment, and on-call. Faster decisions, clearer accountability.
Selective scaling
Scale the Streaming Service to 1,000 instances during peak hours without scaling the Payment Service that handles low-traffic billing events.
Costs
Distributed complexity
Network failures, partial failures, and CAP theorem all become your problem. Operations that were local function calls are now remote calls with timeouts, retries, and circuit breakers.
No distributed transactions
Can't use a single ACID transaction across services. Must use Saga pattern (choreography or orchestration) which is complex to debug and reason about.
Operational overhead
100+ services × metrics + logs + traces + alerts + on-call rotations. Netflix employs a large SRE team. Smaller orgs often can't sustain this overhead.
Latency overhead
Service-to-service network hops add latency. A play request fans out to 5 services — each hop is ~1ms. Monolith function calls are nanoseconds.
Testing complexity
Integration testing across 10+ services requires contract testing (Pact), service virtualization, or a full staging environment. Each adds engineering cost.