Cheat Sheet
Use print-ready and copy-ready revision blocks for the 30-second, 2-minute, and 5-minute interview versions.
On this page
Answer versions
Revise the whole story with fast answer versions, formulas, and mistakes to avoid.
My cheat sheet reduces the full design into a few answer versions, formulas, and red-flag mistakes so I can recall it quickly under interview pressure.
Quick jumps
Click to jumpMonthly users
200M-250M
Docs use both 200M+ and 250M assumptions
Daily active users
80M
Used for heartbeat and Kafka math
Peak concurrency
15M
Useful for QoE and live ops workloads
30-second answer
I will scope this as the data platform behind a Netflix-like company: event ingestion, Kafka, Flink, Spark, Bronze/Silver/Gold lakehouse, warehouse and BI serving, feature store, governance, replay, and reliability.
2-minute answer
Client, CDN, service, search, browse, recommendation, and billing events land through an event gateway into Kafka domain topics. Flink handles real-time sessionization, watch time, QoE, fraud, and online features. Bronze stores immutable raw truth. Spark and dbt clean and enrich into Silver and publish official metrics and features in Gold. BI, warehouse, OLAP, and feature stores serve different consumer workloads. Data quality, governance, replay, and backfills are built in.
Closing statement
The key design principle is that streaming gives speed, batch gives correctness, and the lakehouse gives replayability. I would keep Bronze immutable, make Silver clean and deduplicated, publish official business metrics in Gold, and ensure every pipeline is observable, idempotent, governed, and replayable. For a Netflix-like platform, correctness of watch time, handling late events, sessionization, and backfill strategy are as important as raw scalability.
5-minute architecture walkthrough
Clarify scope as data engineering, not playback APIs or CDN routing.
Lock business requirements, freshness expectations, and correctness boundaries.
Derive scale using DAU, watch time, heartbeat interval, event size, and peak multiplier.
Show client events -> gateway -> Kafka -> Flink + Spark -> Bronze / Silver / Gold -> BI / ML / feature store.
Deep dive into watch time, sessionization, late events, replay, and backfill.
Must mention
Heartbeat is the source of truth for watch time
Streaming gives speed, batch gives correctness
Bronze immutable, Silver trusted, Gold official
Late events are corrected, not silently dropped
DLQ needs owner + replay tooling
Point-in-time correctness for ML features
Common mistakes
Using play and pause only for watch time
Treating streaming dashboards as final finance truth
One giant raw topic instead of domain topics
Ignoring sessionization and duplicate logic
No replay/backfill design
No governance story for watch and search history
Scale numbers
80M DAU
2 hours/day per active user
Heartbeat every 30 seconds
19.2B heartbeat events/day
50-100 TB raw data/day
1M-2M peak events/sec
200-300 partitions across hottest topics
Kafka formulas
Heartbeats per user/day = watch_seconds_per_day / heartbeat_interval
Peak events/sec = daily_events / 86,400 * peak_multiplier
Kafka partitions = ceil(peak_events_per_sec / safe_events_per_partition * headroom)
Watch-time rules
Count only valid heartbeats with active playback
Separate watch_seconds, session_seconds, buffering_seconds, and unique coverage
Use unique coverage for completion_pct
Sessionization rules
Key by user/profile/content/device/session
Close on stop, complete, or inactivity timeout
Allow pause continuation and journey grouping separately
Late-event strategy
On time -> normal process
Late but allowed -> update prior window/session
Very late -> late_events -> correction job -> audited merge
Bronze / Silver / Gold
Bronze = immutable raw events
Silver = cleaned, deduped, schema-valid trusted facts
Gold = official business definitions and curated features
Table names
fact_watch_session
fact_content_impression
fact_search_event
dim_user
dim_content
dim_device
rpt_content_daily_metrics
quarantine_events
backfill_audit
Failure modes
Hot partitions
Checkpoint failure
Schema breaking change
Late-event spike
Bad dedupe logic
Wrong Gold backfill publish
Trade-off one-liners
Kafka for ecosystem and replay, Kinesis for managed simplicity
Flink for low-latency stateful event-time logic, Spark Streaming for stack consolidation
Iceberg for open multi-engine tables and snapshot rollback
Warehouse for curated BI, Trino/Athena for ad hoc lake queries
Last reviewed June 2026 · By Prasoon Parashar
Numbers are interview assumptions, not real Netflix internal figures.