withsoon
N
Cheat Sheet14/14

Netflix System Design

Cheat Sheet

~5 min read

Cheat Sheet

Review, then close — the interview tests recall, not reading.

Opening Scripts

30-second opening
I'd design Netflix's playback backend as a 10-service orchestration chain.
A user clicks Play → Gateway validates JWT → Subscription Service confirms active plan → Concurrency Service
checks stream limits atomically in Redis → Playback Service calls DRM and Manifest Service → client gets
manifest URL and fetches video bytes directly from the nearest Open Connect CDN appliance.
During playback, clients send a heartbeat every 30 seconds. That's 60M concurrent streams ÷ 30s = 2M writes/sec —
which rules out MySQL and drives the choice of Cassandra for watch_progress.
I'll deep dive on concurrency enforcement, watch progress storage, and CDN handoff.
2-minute deep-dive opening
Netflix serves 300M subscribers. I'll assume 220M DAU, 60M peak concurrent streams, 5 Mbps average bitrate.

Functional requirements: start playback, enforce concurrent stream limits, track watch progress for resume, deliver video globally.

Non-functional: availability over consistency for playback (every second of downtime is revenue), sub-2-second playback start, eventual consistency for watch progress (30-second staleness is fine), strong consistency for concurrency and billing.

Scale: 60M streams × 5 Mbps = 300 Tbps CDN bandwidth. 60M ÷ 30s = 2M heartbeat writes/sec. That immediately rules out MySQL.

Architecture: 10-service chain. Gateway → Auth → Subscription → Concurrency (Redis Lua) → Playback → DRM (fail-closed, legal) → Manifest → CDN. Watch Progress is an async write path — it doesn't block session start.

Key DB decisions: Cassandra for watch_progress (2M writes/sec, partition by profile_id), Redis for concurrency state (atomic Lua script, 60 GB for 60M sessions), MySQL for billing (ACID), EVCache for metadata (99.9% hit rate at 30M req/s).

Key tradeoff: DRM is the only fail-closed service — legal requirement. Everything else fails open. Watch progress uses eventual consistency by design.

Main Services (10)

API GatewayJWT validation, rate limiting, routing
Auth ServiceIdentity verification, session token issuance
Subscription ServicePlan validity check — fail open (availability)
Concurrency ServiceStream limit enforcement — Redis Lua, fail closed
Playback ServiceOrchestrates DRM + Manifest, returns session to client
DRM ServiceLicense issuance — fail closed (legal requirement)
Manifest ServiceReturns ABR manifest with CDN URLs
Watch Progress ServiceHeartbeat upsert to Cassandra — async, not blocking
Metadata ServiceContent metadata reads via EVCache → Cassandra
CDN / Open ConnectVideo delivery, 300 Tbps, ISP-peered appliances

API List (5 core)

POST/v1/playback/sessionsIdempotent on client session_id
POST/v1/playback/heartbeatIdempotent on session_id + event_ts
DELETE/v1/playback/sessions/{id}Removes from Redis, marks Cassandra row
GET/v1/watch-progress/{profile_id}Returns all in-progress content
GET/v1/metadata/{content_id}Returns from EVCache, fallback Cassandra

Database Choices

Cassandrawatch_progress, playback_sessions, content_metadata

2M writes/sec, partition by profile_id, ONE consistency

Redisactive_streams (concurrency), session tokens

Atomic Lua script for concurrency check, 60 GB fits in memory

MySQLuser_accounts, billing, subscriptions

ACID required — double-charge is catastrophic

EVCache (Memcached)Content metadata cache

30M req/s at 99.9% hit rate, in-process cache

Cache Strategy

CacheEVCache (Memcached, in-process)
What's cachedContent metadata, catalog, user preferences
Hit rate99.9% — 30K Cassandra reads/sec at 30M total reads/sec
Cache missMutex lock — one filler thread, others wait. Prevents thundering herd.
InvalidationWrite-invalidate on content rights change. TTL 1 hour.

Playback Flow (15 steps)

1

POST /playback/sessions (client sends session_id UUID)

2

Gateway: validate JWT

3

Auth Service: verify identity

4

Subscription Service: check plan — fail open

5

Concurrency Service: Redis Lua atomic check-and-add — fail closed

6

Playback Service: orchestrate downstream

7

DRM Service: issue device-bound license — fail closed (legal)

8

Manifest Service: return ABR manifest with CDN URLs

9

Response: manifest_url + drm_license_url + heartbeat_interval_sec

10

Client: parse manifest

11

Client: fetch first segment from nearest OCA appliance

12

CDN: serve video bytes (no API involvement)

13

Client: start heartbeat loop every 30s

14

Heartbeat: POST /heartbeat → Watch Progress → Cassandra ONE write

15

Session end: DELETE session → Redis SREM + Cassandra update

Top 5 Failures

DRM Service down

Fail closed — no playback. Legal requirement.

Redis (concurrency) down

Fail open with fallback count check in Cassandra

EVCache cold start

Thundering herd — mutex lock on miss, one filler thread

Cassandra heartbeat write fails

Client retries with exponential backoff; eventual consistency means 30s staleness is ok

CDN node fails

Client retries to parent cluster → origin S3. API layer is unaffected.

Top 4 Tradeoffs

Strong consistencyvsEventual consistency

Strong: concurrency (Redis), billing (MySQL). Eventual: watch progress (Cassandra ONE).

RedisvsCassandra

Redis for concurrency (atomic ops). Cassandra for write-heavy time-series data.

Fail closedvsFail open

DRM: fail closed (legal). Subscription: fail open (availability > revenue loss).

Sync writesvsAsync writes

Watch progress is async — doesn't block session start. Billing is sync.

Scale Numbers (memorize the derivation, not the number)

300M subscribers × 0.73= 220M DAU
220M × 0.27 peak= 60M concurrent streams
60M × 5 Mbps= 300 Tbps CDN
60M ÷ 30s heartbeat= 2M writes/sec → Cassandra
30M metadata reads/sec × 99.9%→ 30K reach Cassandra
60M × 1KB Redis SET entry= 60 GB Redis for concurrency
2M writes/sec ÷ 200/node= ~10,000 Cassandra nodes
Last reviewed June 2026 · By Prasoon ParasharNumbers are interview assumptions, not real Netflix internal figures.
Was this tab useful for interview prep?