Progress
1 visited · 0 revised
Chapter
4 / 10
On this page
Event envelope
Make one event contract every downstream system can trust
Show the few fields that make retries, ordering, freshness, and schema evolution understandable.
Canonical event envelope
Hover or click a field to see why it exists.
Why this field matters
⏱️ event_time
The moment the user action happened. Windows, freshness, and point-in-time joins should anchor here.
Interview use
This is how you separate user truth from platform delay.
Example
Example: the member pressed play at 8:00:00 PM, even if the platform sees the record a few seconds later.
Dedup
event_id
Logical retries
Truth time
event_time
Windows and PIT joins
Delay
ingest_ts
Freshness and bad clocks
Choose ordering before scaling
Make it obvious why session_id works for playback, why title_id can go hot, and how partition count is derived.
Topic key picker
Choose the source key, then see the ordering trade-off immediately.
Why teams pick it
All events for one playback journey land on the same partition, so the stream processor sees play, pause, seek, heartbeat, and stop in the right sequence without cross-partition stitching.
What can go wrong
You preserve ordering only inside one session. If the same member starts a second session on another device, those two sessions can be processed independently and are not globally ordered at member level.
Recommended use
Best default for playback topics because session correctness matters more than cross-session ordering.
Example
If `session_id = s_9812`, every heartbeat for that movie session hashes to one partition. A Flink keyBy on session_id can then hold one keyed state object and compute watch time without repartitioning first.
Partition math
Keep the board formula visible.
Peak topic throughput
1.2M events/sec
Safe partition rate
5K events/sec
Base partitions
1,200,000 / 5,000 = 240
Headroom
240 x 1.25 = 300
Keep trust, history, and cost under control
Late data, SCD2, quality gates, and storage discipline should feel like one compact operating model.
Guardrails
Pick one and see what it protects in the pipeline.
Selected guardrail
🧠 SCD2 + point-in-time joins
Facts should join to the dimension row valid at the event timestamp, not the latest row today.
plan changes
title metadata fixes
experiment config history
unknown key then repair
Scenarios
What happens
A member watched on the Standard plan yesterday and upgrades to Premium today. Yesterday's watch fact must still resolve to the Standard-plan dimension row.
Technical implication
A title's genre mapping is corrected next week, but last month's report should still use the dimension version that was valid at the original watch timestamp.
One clear answer
Keep it short and centered on contracts, ordering, and stable business truth.
Interview answer
I define one canonical event envelope first, then choose Kafka keys for ordering, then turn clean Silver events into conformed facts and dimensions so every dashboard, experiment, and model reads the same business truth.
Last reviewed June 2026 · By Prasoon Parashar
Numbers are interview assumptions, not real Netflix internal figures.