01
Streaming Jobs Kafka Topics Playback · engagement
-> Live Counters i Approximate views by video What it does: Maintains seconds-old view and engagement totals for each video.How: Aggregate sharded video keys into short time buckets, deduplicate event_id, then upsert the latest bucket version.Example: A live concert's counter refreshes every few seconds while nightly batch later certifies the official total.Trending i Velocity over sliding windows What it does: Finds videos gaining attention now, rather than videos with the largest lifetime count.How: Compare view and engagement velocity across overlapping windows, then add freshness, diversity, quality, and abuse features.Example: A new upload moving from 2K to 80K regional views in ten minutes can outrank an old video with a larger static total.Watch Time i Sessions from heartbeats What it does: Turns noisy playback heartbeats into validated played time for one playback attempt.How: Key by viewer plus playback_attempt_id, order by event time, remove retries, and update session state only for valid playback deltas.Example: Playing heartbeats add time; buffering and paused intervals remain separate and do not inflate watch time.Fraud Signals i Flag suspicious spikes What it does: Produces fast evidence that a view or engagement spike may be artificial.How: Maintain short-lived counters and sequence patterns by device, account, network, video, and campaign; publish flags for review or discounting.Example: Thousands of identical watch attempts from a small device cluster raise a signal before those events become certified counts.Online Features i Recent viewer activity What it does: Keeps recommendation features fresh between offline training runs.How: Update timestamped values such as recent watches, searches, topic affinity, and short-term popularity in an online feature store.Example: After a viewer watches three guitar tutorials, the next recommendation request can use that recent sequence immediately.QoE Monitor i Buffering and error alerts What it does: Detects live playback-quality regressions by region, app version, device, ISP, or CDN path.How: Aggregate buffer starts, startup delay, fatal errors, bitrate changes, and playback failures in short event-time windows.Example: A rebuffer spike isolated to TV app version 9.4 in one region pages the owning playback team.
-> Live Outputs Pinot · Redis
02
Session State Normal path
video_start -> Started heartbeat (PLAYING) -> Playing video_end / complete -> Ended
Playing self-loop: each valid PLAYING heartbeat adds a bounded played delta and updates last_valid_event_time.
Branches from Playing
PLAYING -> BUFFERING -> PLAYING buffering heartbeat -> playing heartbeat Buffering path Stop adding played time while the player reports BUFFERING. Continue the same session when a later PLAYING heartbeat arrives, and add the buffered duration only to buffering_ms.PLAYING -> PAUSED -> PLAYING pause -> resume Paused path A pause keeps the session open but contributes no watch time. Resume returns to Playing unless the inactivity rule already closed the session.PLAYING -> SEEKING -> PLAYING seek -> playing heartbeat Seeking path A seek changes playback position. The next valid Playing heartbeat establishes the new position; impossible jumps are flagged instead of being counted as watched content.PLAYING -> CLOSED inactivity > watermark + grace Closed path If an app crashes or never sends video_end, the event-time timer closes the partial session. A permitted late event updates the same session key with a higher version.
Late/offline event: reopen the same playback-attempt key, recalculate the session, and emit a versioned upsert—never a duplicate fact.
Identity, Timing, Playback, Experience, and Correctness are not separate services. They are five groups of fields inside one Flink state record for one playback attempt.
heartbeat / pause / seek -> find attempt p-42 -> read + update its state -> apply session rules -> emit p-42 version N
Inside one state record
Identity i Which playback attempt? What it does: Fields that identify the one playback attempt being reconstructed and the permissions attached to it.How: Flink uses viewer identity plus playback_attempt_id to locate the correct state object. Consent limits downstream use; client version helps trace producer defects.Example: Every event for attempt p-42 loads the same state record, while events for the viewer's next video load a different record. Fields: playback_attempt_id, consent_state, client_versions.Timing i When did it happen? What it does: Event-time boundaries for the beginning and latest valid activity in this attempt.How: They order delayed heartbeats, calculate inactivity, and fire the timer that closes a session when no end event arrives.Example: The last valid event was 10:04. When the watermark passes the inactivity deadline, Flink closes p-42. Fields: session_start_event_time, last_valid_event_time.Playback i How much was watched? What it does: The progress needed to calculate played time and distinct video coverage.How: A valid heartbeat moves last_position_ms and adds a bounded delta to total_played_ms. Covered ranges track which content intervals were actually seen.Example: Rewatching seconds 30-40 adds ten played seconds but does not add ten new seconds of unique coverage. Fields: last_position_ms, total_played_ms, unique_covered_ranges.Experience i Was playback healthy? What it does: Playback behavior and quality measures stored separately from active watch time.How: Buffer, pause, and seek transitions update their own counters so product and infrastructure teams can diagnose the viewing experience.Example: A 12-second buffer increases buffering_ms by 12 seconds and adds zero seconds to active watch time. Fields: buffering_ms, pause_count, seek_count.Correctness i Can this update be trusted? What it does: Guards that prevent retry duplicates and let a late event safely correct an existing session.How: Ignore an event_id already seen. When accepted late data changes p-42, emit the same session key with a higher late_update_version.Example: A repeated heartbeat e-17 is ignored; a new delayed heartbeat e-18 changes p-42 from version 2 to version 3. Fields: seen_event_ids, late_update_version.
Rules applied after each event
Valid Playback i Only playing time contributes Rule A heartbeat adds a bounded played delta only when the state and event sequence show real playback. Buffering and paused time remain separate.Rewind i Played time and coverage differ Rule Rewatching ten seconds may add ten seconds to total_played_ms, but those seconds do not expand unique_covered_ranges if that segment was already viewed.Bad Delta i Quarantine impossible movement Rule Negative deltas, impossible position jumps, excessive clock skew, and unsupported state transitions are flagged or quarantined instead of changing watch time.Close i End event or inactivity Rule video_end or complete closes immediately. If a player crashes and sends neither, an event-time inactivity timer closes the partial session.Late Reopen i Emit a newer version Rule A permitted late heartbeat reopens the session state, recalculates totals, and emits the same playback-attempt key with a higher version—not a second fact.
03
Time + Windows Event Time i When playback happened What it does: Windows use the timestamp carried by the playback event, not the moment Flink receives it.How: Assign timestamps from the trusted event field and preserve ingest time separately for delay monitoring.Example: A heartbeat created at 10:02 but received at 10:07 still belongs to the 10:02 playback window.Watermark i Progress with bounded waiting What it does: A watermark estimates how far event time has progressed and tells Flink when most earlier events should have arrived.How: Choose lateness from measured mobile and TV delay distributions, then add a documented grace period.Example: At watermark 10:10 with five-minute allowed lateness, a 10:02 window can close while exceptional arrivals use a correction path.Tumbling Window i One fixed bucket What it does: Creates non-overlapping buckets for simple periodic totals.How: Assign each event to exactly one minute, five-minute, or hourly interval.Example: Live dashboard cards read one-minute view counts such as 10:02:00 through 10:02:59.Sliding Window i Overlapping trend signal What it does: Recomputes a rolling interval frequently so momentum changes are visible quickly.How: Use a window such as the last ten minutes, advanced every minute.Example: Trending compares the newest ten-minute view velocity every minute instead of waiting for a fixed bucket to end.Session Window i One playback attempt What it does: Groups events separated by short gaps into the same viewing session and closes after inactivity.How: Key by privacy-approved viewer identity plus playback_attempt_id and use an inactivity timer.Example: Play, heartbeats, pause, resume, seek, and end for attempt p-42 produce one versioned watch-session row.Backpressure i A slow task blocks upstream What it does: A consumer task receives work more slowly than Kafka and upstream operators produce it.How: Inspect per-task busy time and lag, then fix skew, increase parallelism, tune state/checkpoints, or protect a slow sink.Example: One viral-video key saturates a task; sharding that video removes the bottleneck instead of only adding idle consumers.
Late mobile heartbeat
Put delayed playback back into the session where it happened Example allowance: 5 min 10:02 Heartbeat created The phone records event_time=10:02 for playback attempt p-42. ->
Offline Stored on phone The tunnel has no signal, so the SDK keeps the event in its bounded local queue. ->
10:07 Arrives at Flink The network returns five minutes later. Processing time is 10:07, but event time remains 10:02. ->
Place Use event time Flink puts the heartbeat into p-42's original session instead of treating it as new activity at 10:07. ->
Correct Upsert p-42 v3 The session total is recalculated and the sink replaces p-42 version 2 with version 3.
Arrives after the live allowance? Send it to a late-event side output -> retain it in Bronze -> nightly batch updates the official session and daily totals. The event is delayed, not discarded.
The five-minute allowance is an interview assumption. In production, choose it from measured mobile/TV delay distributions and the freshness target.
Exactly Once i Checkpoint + idempotent upsert What it does: Prevents a recovered job from changing one logical metric twice.How: Restore Flink state and Kafka offsets from the same checkpoint, then write outputs by stable key and version.Example: After a crash, watch session p-42 is replayed but replaces the same versioned row rather than adding another session.Live vs Official i Fast estimate, certified batch truth What it does: Streaming serves seconds-old decisions while batch owns final deduplicated and fraud-filtered history.How: Publish live values as provisional and let the certified nightly output overwrite the historical window.Example: Creator Studio shows a fast view estimate now; the next certified run publishes the official count after late-event and abuse reconciliation.
04
Output Contracts Output Stable key Update model
Live video counter video + time bucketUpsert / shard merge i Explanation Each video shard emits a partial bucket count. A merge stage combines those partials and upserts the current video-and-time-bucket value.Watch session playback attemptVersioned upsert i Explanation The sink stores one logical row for p-42. A late heartbeat writes p-42 version 4, replacing version 3 rather than creating a duplicate session.Trending feature video + region + windowReplace window version i Explanation A feature row is reproducible for one video, region, window, and formula version. Later evidence replaces the same window version safely.QoE alert metric + region + clientAppend by incident i Explanation Alerts are append-only facts attached to a stable incident key so repeated evaluations update or enrich the same operational incident.Online feature entity + featureLatest event-time value i Explanation The online store accepts the value with the newest event timestamp, preventing an older delayed update from overwriting a more recent feature.
05
Trending Problem being solved: find trustworthy videos gaining meaningful attention now for each region—not the videos with the largest lifetime totals.
Eligible Events deduped views · watch depth
-> Sliding feature window: last 10 minutes, refreshed every minute
View Velocity i Is attention arriving quickly? What it does: Qualified views per minute in the current sliding window.How: Count deduplicated, eligible views for each video and region over the latest ten minutes.Example: Video A receives 80K eligible views in ten minutes while Video B receives 10K.Acceleration i Is growth getting faster? What it does: The change in view velocity between adjacent windows.How: Compare the newest view rate with the preceding rate instead of looking only at the current total.Example: Video A rises from 2K/min to 8K/min, which is stronger momentum than a steady 8K/min.Unique Viewers i Is the audience broad? What it does: An approximate distinct count of eligible viewers in the window.How: Use a privacy-safe distinct-count sketch so repeated plays from the same viewer do not look like broad demand.Example: 50K views from 45K viewers is broader than 50K views from 900 viewers.Geo Diversity i Is interest distributed? What it does: How widely interest is spread across allowed geographic buckets.How: Measure concentration across countries or regions and retain regional rankings rather than forcing one global list.Example: A video rising across 20 regions receives a broader-interest signal than the same count from one small network.Engagement Quality i Are viewers meaningfully engaged? What it does: Evidence such as watch depth, meaningful likes, comments, and shares.How: Combine normalized engagement rates with watch behavior so a click alone cannot dominate the score.Example: Two videos have equal starts, but the one with stronger watch depth and shares receives the higher quality signal.Freshness i Is the momentum recent? What it does: A time-decay signal that favors recent momentum over old accumulated popularity.How: Reduce the contribution of older windows with a versioned decay rule.Example: A new upload rising this hour can surface ahead of a year-old video with a much larger lifetime total.Abuse Penalty i Does the traffic look trustworthy? What it does: A negative signal based on invalid traffic and suspicious viewing patterns.How: Discount flagged devices, accounts, networks, campaigns, and coordinated bursts before ranking.Example: A bot-driven spike loses score even when its raw view velocity is high.
Momentum: View Velocity + Acceleration Audience: Unique Viewers + Geo Diversity Quality: Engagement Quality + Freshness Trust: Abuse Penalty
-> Versioned Policy combines auditable features
Fast growth + broad audience + strong engagement - abuse -> regional trending candidates
06
Runtime + Operations Where the engine fits
Kafka ordered event streams
-> Flink Runtime runs session, trending, fraud, QoE, counter, and feature jobs
-> Serving + Storage Pinot · Redis · alerts · lake
Operations surround this runtime. They detect lag, preserve state during failure, control memory, support upgrades, rescale jobs, and verify that outputs still commit.
Apache Flink i Preferred · event-at-a-time What it does: Provides low-latency event processing with rich keyed state, event-time timers, checkpoints, and side outputs.How: Use it for playback sessionization, fraud patterns, live counters, QoE alerts, and online features.Example: A late p-42 heartbeat updates its keyed session immediately while checkpointed state protects recovery.Spark Structured Streaming i Valid · micro-batch What it does: Processes small batches continuously and fits teams already operating Spark.How: Choose it when existing skills and lake integrations matter more than the lowest per-event latency.Example: A several-second micro-batch can serve dashboard aggregates when the latency target does not require event-at-a-time timers.
Checkpoint Health i Production control Explanation Watch checkpoint duration, failures, alignment time, and stored state size. A growing checkpoint can make recovery slower than the freshness SLO.Event-Time Lag i Production control Explanation Measure now minus the newest processed event_time. Low CPU latency can still hide five-minute-old playback data.Watermark Progress i Production control Explanation Track each partition's watermark and the distribution of late events. One idle or delayed partition must not freeze every window.Savepoints i Production control Explanation Take a controlled state snapshot before changing code or topology so the YouTube job can be upgraded or rolled back without discarding sessions.State TTL i Production control Explanation Expire dedup IDs, completed sessions, window buckets, and inactive keys after their correction horizon so state does not grow forever.Rescaling i Production control Explanation Document how keyed state redistributes when parallelism changes; validate recovery time and skew before a traffic event.Sink Commit i Production control Explanation Monitor upsert conflicts, transaction aborts, retries, and commit age so a healthy Flink graph cannot hide a stalled Pinot, Redis, or lake sink.Canary Compare i Production control Explanation Run the new job beside the old version on the same events, compare output by key and window, then expand only after differences are understood.
07
Interview Answer Goal: turn continuous playback and engagement events into seconds-old watch sessions, counters, trends, alerts, and recommendation features without letting retries or delayed phones corrupt the results.
1. Bring together Send every event for one playback attempt to the same Flink worker.
2. Reconstruct Use event time and state to understand play, pause, buffering, seek, and completion.
3. Compute live Produce watch time, video velocity, QoE, fraud, and recommendation signals.
4. Correct safely Deduplicate retries and replace an older session version when delayed data arrives.
5. Certify later Let nightly batch reconcile complete history and publish the official numbers.
Say this The goal of the real-time layer is to turn raw YouTube activity into useful signals within seconds while keeping playback sessions correct. I route all heartbeat, pause, seek, buffer, and end events for the same playback attempt to one Flink worker so it can rebuild that attempt in order and maintain its state. Event time and watermarks place delayed mobile events into the session where they happened; duplicates are ignored by event ID, and accepted late changes replace the older session version. Separate streaming jobs produce live video counters, trending features, fraud signals, QoE alerts, and recent recommendation features. These outputs are provisional for fast product decisions, while the nightly batch pipeline publishes the final deduplicated and fraud-filtered truth.
