Contents
8 entity groups · scroll to follow along
Netflix System Design
Data Models
Read this like a compact ER diagram: each schema card keeps table name, fields, types, keys, storage reason, and access patterns close together.
User & Profile
User accounts and profiles need ACID transactions, referential integrity (CASCADE DELETE), and complex JOIN queries for billing dashboards. DynamoDB can't enforce FK constraints or run multi-table transactions without application-level orchestration. Billing errors that charge real money require strong consistency — Aurora is the only choice.
Schema
user_id
password_hash
subscription_tier
plan_type
region
country_code
device_limit
created_at
updated_at
deleted_at
Why Aurora
Aurora because billing identity needs ACID transactions, FK constraints to subscriptions/payment_methods, and GDPR hard-delete semantics — none of which DynamoDB can enforce natively.
Access
→ get by email (login)
→ get by user_id (profile load)
→ list all for billing reports (rare)
profile_id
user_id
name
avatar_url
is_kids
max_rating
language_pref
pin_hash
created_at
Why Aurora
Aurora because profiles are a child entity of users (FK → ON DELETE CASCADE) and are always read with a JOIN to users for access-control checks — keeping them in the same RDBMS avoids cross-store transactions.
Access
→ get profiles by user_id
→ get profile_id for JWT
→ check is_kids for catalog filtering
Anti-Patterns to Avoid
- ✗Don't store watch history here — 500K writes/sec would kill Aurora
- ✗Don't store content metadata here — 50K RPS read throughput needs DynamoDB
- ✗Don't store session tokens here — sub-ms access needs Redis
Interview Tip
Distinguish User (billing entity) from Profile (viewing persona) immediately. Interviewers test this.
Scaling Note
At 10× scale: read replicas + PgBouncer pooling stays the same pattern, just more replicas. Aurora Serverless v2 for burst workloads. The schema doesn't change.
Content & Episode
Content metadata is read-heavy at 50,000 RPS with well-defined access patterns: get-by-id, list-by-genre, get-episodes-of-series. DynamoDB delivers single-digit ms at any scale, deploys globally with zero ops, and the flexible document model handles the wide variety of content attributes (movie vs series vs short). No JOINs needed — all reads are single-entity lookups.
Schema
PK: content_id
SK: 'METADATA'
title
type
genres
cast
director
release_year
maturity_rating
thumbnail_url
available_regions
duration_secs
duration_minutes
description
Why DynamoDB
DynamoDB because content metadata is read-heavy at 50 K RPS with fully predictable access patterns (get-by-id, list-by-genre). Schemaless attributes handle the wide variation between movies, series, and shorts without NULL columns or ALTER TABLE migrations.
Access
→ get content by ID → PK=content_id, SK=METADATA
→ list by genre sorted by year → genre-index GSI
→ get all episodes in series → PK=series_id, SK begins_with 'S'
PK: series_id
SK: 'S{n}E{n}'
episode_id
title
duration_minutes
thumbnail_url
description
release_date
Why DynamoDB
DynamoDB because episodes belong to a series (same partition key), so get-all-episodes is a single Query with no cross-partition scatter — impossible to match with a relational range scan at this read throughput.
Access
→ get all episodes for a series → PK=series_id, SK begins_with 'S'
→ get specific episode → PK=series_id, SK='S02E05'
→ get latest season → sort by SK descending
Anti-Patterns to Avoid
- ✗Don't run ad-hoc analytics here — use OpenSearch or Redshift for 'find all titles released in 2022 with rating > 7'
- ✗Don't store watch history here — wrong access pattern (time-series) and wrong throughput profile
- ✗Don't run full-text search here — DynamoDB has no text index, use OpenSearch for that
Interview Tip
State access patterns before table design. Interviewers want to hear 'I defined 3 access patterns upfront: get-by-id, list-by-genre, get-episodes.' That's DynamoDB design thinking.
Scaling Note
At 10× scale: on-demand capacity auto-scales, no changes needed. Add a global secondary index if a new access pattern emerges — don't redesign the table.
Watch History
500K writes/second at peak (all concurrent viewers sending 30s heartbeats). Cassandra is purpose-built for this: linear write scale across nodes, time-series data partitions naturally by user, native TTL eliminates cleanup jobs, and eventual consistency is acceptable for watch progress.
Schema
profile_id
content_id
episode_id
progress_sec
updated_at
completed
Why Cassandra
Cassandra because this table absorbs 500 K heartbeat writes/sec — its LSM-tree engine turns random writes into sequential I/O, and partitioning by profile_id keeps each resume-position lookup a single-node O(1) read.
Access
→ get resume position → PK=profile_id, CK=content_id (O(1))
→ list all in-progress content for 'Continue Watching' row → PK=profile_id, limit 10
profile_id
year
watched_at
content_id
episode_id
progress_sec
duration_sec
bitrate_kbps
Why Cassandra
Cassandra because this is an append-only time-series log; year-bucketed composite partition key prevents hot partitions for power users, and native TTL auto-expires old records without a batch delete job.
Access
→ get recent watch history for reco model → PK=(profile_id, current_year), newest first
→ get watch history across years → query (profile_id, 2024) + (profile_id, 2023) and merge in app
Anti-Patterns to Avoid
- ✗Don't use a single partition key of profile_id alone — unbounded partition growth for power users
- ✗Don't use QUORUM reads — LOCAL_ONE is correct here, read freshness doesn't matter for 3-second-stale data
- ✗Don't store this in Aurora — 500K writes/sec would require extreme sharding and connection pool management
Interview Tip
Explain the TWO table design: watch_progress (upsert, current position) vs watch_history (append-only, full log). They serve different consumers. Mentioning this distinguishes senior candidates.
Scaling Note
At 10× scale: add nodes (Cassandra scales linearly). Bucket partition key by month instead of year. Consider Scylla DB (same CQL API, 10× throughput on the same hardware).
Playback Session
An active playback session is a hot, ephemeral object: the player pings it every 30 seconds, and once the user stops watching it should vanish automatically. Redis holds the live session for sub-ms reads on the streaming hot path; DynamoDB persists an audit record for device-limit enforcement, GDPR exports, and post-session analytics.
Schema
Key: session:{session_id}
user_id
content_id
device_id
quality_level
position_ms
started_at
TTL: 90s
Why Redis
Redis because the 30-second heartbeat from every concurrent viewer is the highest-write-rate operation in the system — Redis SETEX is the only store that absorbs this with sub-ms latency and automatic TTL expiry.
Access
→ heartbeat upsert → SETEX session:{session_id} 90 {json} (every 30s)
→ device-limit check → SCAN 0 MATCH session:* COUNT 100, filter by user_id (or use a secondary set key: user_sessions:{user_id})
→ stop session → DEL session:{session_id}
PK: session_id
SK: 'SESSION'
user_id
content_id
device_id
started_at
last_heartbeat
position_ms
quality_level
status
TTL
Why DynamoDB
DynamoDB for durable audit: device-limit enforcement queries (all active sessions for a user), GDPR data exports, and post-session analytics fan-out to Kinesis — Redis alone cannot serve these multi-minute retention queries.
Access
→ check device limit → query user-sessions-index GSI, PK=user_id, filter status=ACTIVE
→ end session → UpdateItem status=COMPLETED, position_ms, last_heartbeat
→ GDPR export → query user-sessions-index, all records for user_id
Anti-Patterns to Avoid
- ✗Don't store the in-flight session only in DynamoDB — even with DAX, the 30s heartbeat write cadence at 15M concurrent viewers overwhelms provisioned WCU budgets
- ✗Don't store the in-flight session only in Redis — a Redis restart during a popular event (World Cup final) would drop all active sessions simultaneously
- ✗Don't use a relational DB for session state — connection-count exhaustion at 15M concurrent writes is a known failure mode
Interview Tip
Explain the Redis + DynamoDB split by lifecycle: Redis owns the 'alive' window (30s TTL refresh), DynamoDB owns the audit record. Both writes happen on session start; only Redis is on the 30s heartbeat path.
Scaling Note
At 10× scale (150M concurrent): Redis cluster shards by session_id prefix across 32+ nodes. DynamoDB on-demand absorbs burst without provisioning changes. The critical insight: heartbeat writes go only to Redis — DynamoDB write rate is bounded by session starts/ends, not heartbeats.
Watch History (DynamoDB)
The DynamoDB watch history table complements the Cassandra write-path log: it is the queryable, durable, globally-replicated record for the recommendation engine, the 'My Activity' GDPR export, and the account settings page. DynamoDB Global Tables replicate to 3 regions with <1 s replication lag, and the composite sort key (watched_at#content_id) enables time-range queries and per-title deduplication in a single index.
Schema
PK: user_id
SK: watched_at#content_id
content_id
episode_id
watched_at
progress_secs
duration_secs
completed
device_id
quality_level
TTL
Why DynamoDB
DynamoDB because the recommendation service and 'My Activity' page need globally-replicated, durable, queryable watch records with time-range access — Cassandra is fine for the write path but DynamoDB Global Tables give zero-ops multi-region replication the reco service depends on.
Access
→ get watch history for reco model → PK=user_id, SK begins_with '2024-' (last 90 days)
→ check if user watched title → PK=user_id, SK begins_with '{watched_at_prefix}#{content_id}'
→ GDPR full export → PK=user_id, all records (paginated)
Anti-Patterns to Avoid
- ✗Don't use user_id alone as the PK — unbounded item collections for power users create hot partitions
- ✗Don't store raw video analytics here — use Kinesis Data Firehose → S3 → Athena for event-level telemetry
- ✗Don't use scan for 'recently watched' — always Query with a time-range SK condition to avoid full-partition reads
Interview Tip
The composite SK (watched_at#content_id) is the interviewer's litmus test. It lets you answer 'did user watch title X last week?' with a single Query (no FilterExpression) AND prevent duplicate entries for the same title on the same day — two requirements, one key design.
Scaling Note
At 10× scale: partition by (user_id, year) composite key exactly like the Cassandra table — prevents unbounded growth for power users who watch 10 titles/day × 10 years. Or use DynamoDB time-to-live to keep only 12 months and archive older records to S3.
Subscription & Payment
Payment data requires ACID transactions — the state machine transition (ACTIVE → PAST_DUE → CANCELLED) and the corresponding billing action must be atomic. PCI DSS compliance is simplified by Stripe handling raw card data; we only ever store Stripe tokens.
Schema
subscription_id
user_id
plan_type
status
stripe_sub_id
current_period_start
current_period_end
cancelled_at
created_at
Why Aurora
Aurora because subscription state transitions (ACTIVE → PAST_DUE → CANCELLED) must be atomic with the Stripe webhook update — a DynamoDB conditional write can't enforce the state machine invariants that billing correctness requires.
Access
→ check subscription status for streaming access gate → PK=subscription_id OR by user_id
→ update status on Stripe webhook → by stripe_sub_id (unique index)
→ list all past_due for grace period job → status index
pm_id
user_id
stripe_pm_id
card_last4
card_brand
card_exp_month
card_exp_year
is_default
created_at
Why Aurora
Aurora because we need a partial unique index (only one is_default=true per user) — a constraint only expressible in a relational engine; the write frequency is low (one write per card add/remove) so Aurora throughput is not a bottleneck.
Access
→ get default payment method for user → user_id + is_default=true
→ list all payment methods for account page → user_id
Anti-Patterns to Avoid
- ✗NEVER store raw card numbers — only Stripe payment_method tokens
- ✗Don't manage subscription retries yourself — Stripe Smart Retries does this better
- ✗Don't skip idempotency keys on Stripe API calls — crash-and-retry will double-charge without them
Interview Tip
Lead with PCI DSS: 'We never store card numbers — only Stripe tokens, so our PCI scope is minimal.' Then walk the state machine.
Scaling Note
At 10× scale: sharding by user_id prefix becomes necessary if Aurora write throughput is the bottleneck. Subscriptions table grows linearly with users but write rate is low (one write per billing event per month).
Session & DRM License
Sessions split across two stores by access pattern: refresh tokens live in Redis for sub-millisecond lookup on every token refresh (happens every 15 min per user). DRM licenses and device sessions live in DynamoDB for durability — we need license records to survive Redis restarts and for audit/revocation purposes.
Schema
Key: refresh:{uuid}
Value: user_id
TTL: 2,592,000s
Why Redis
Redis because token validation happens on every API call (every 15 min per active session at scale) — sub-ms GET is mandatory; TTL is automatic and DEL gives instant revocation without a full-table scan.
Access
→ GET refresh:{token} → user_id (token refresh, every 15min per active session)
→ DEL refresh:{token} (logout, single device)
→ KEYS refresh:{user_id}:* + DEL all (logout all devices — use scan in prod)
PK: user_id
SK: session_id
device_type
device_fingerprint
ip_address
last_active
created_at
TTL
Why DynamoDB
DynamoDB because session records must survive Redis restarts (durability) while still delivering single-digit ms for list-sessions-by-user — the 'manage devices' page in account settings.
Access
→ list all sessions for user (account settings page) → PK=user_id
→ delete specific session (remote logout) → PK=user_id, SK=session_id
PK: profile_id
SK: license_id
content_id
drm_system
device_fingerprint
issued_at
expires_at
TTL
Why DynamoDB
DynamoDB because license records need durable audit trail (revocation, GDPR) plus a built-in TTL to auto-expire 8 h/48 h licenses — no cron job required; access pattern is always by profile_id making PK design trivial.
Access
→ check active license for device (playback validation) → PK=profile_id, filter content_id+device
→ revoke all licenses for user (GDPR / account compromise) → scan PK=profile_id, delete all
Anti-Patterns to Avoid
- ✗Don't store refresh tokens only in Redis — Redis restarts would log out all users simultaneously
- ✗Don't store DRM license keys in the application database — use CloudHSM, keys never leave hardware
- ✗Don't use long DRM license TTLs — short TTLs bound the blast radius of a compromised device
Interview Tip
Explain WHY two stores: Redis for speed (token refresh critical path), DynamoDB for durability (license audit, device revocation). Single-store designs fail either speed or durability.
Scaling Note
At 10× scale: Redis cluster shards by user_id prefix. DynamoDB on-demand scales automatically. No schema changes needed.
Notification Preferences
Notification preferences are read on every notification send (low throughput, simple key-value lookup by user_id). DynamoDB's flexible schema means adding a new notification type (e.g. 'live_sports_alert') = new attribute, no ALTER TABLE, no migration, no downtime.
Schema
PK: user_id
email_new_episodes
email_billing
push_recommendations
push_continue_watching
sms_security_alerts
marketing_emails
updated_at
Why DynamoDB
DynamoDB because preferences are a simple key-value lookup by user_id and the schemaless model allows adding new notification types (e.g. live_sports_alert) as new attributes without ALTER TABLE or deployment downtime.
Access
→ get preferences for user → PK=user_id (on each notification send)
→ update preference (user settings page) → PK=user_id, UpdateItem specific attribute
PK: user_id
SK: {type}#{timestamp}
channel
template_id
status
sent_at
TTL
Why DynamoDB
DynamoDB because this is an append-only deduplication log; composite SK (type#timestamp) enables idempotency checks with a single range Query, and 90-day TTL auto-purges without a cron job.
Access
→ deduplication check → query PK=user_id, SK begins_with 'billing#' in last 24h — prevents duplicate billing emails
→ list recent notifications for user (UI) → PK=user_id, sort by SK DESC, limit 20
Anti-Patterns to Avoid
- ✗Don't store notification content here — only preferences (boolean flags)
- ✗Don't put notification log in the same table as preferences — different access patterns, different TTL needs
- ✗Don't use a relational schema here — adding a new notification type requires a column migration in SQL
Interview Tip
The key insight: DynamoDB's schemaless flexibility means new notification types ship without schema migrations. At Netflix's release cadence (200+ deploys/day), zero-migration schema changes are operationally valuable.
Scaling Note
At 10× scale: throughput scales automatically (on-demand). Consider write-through cache if pref reads become a hot path.