You are in a system design interview at Amazon for an SDE-3 role and the interviewer has given you the question to Design Netflix. He then asks a follow up to you:
How does Netflix knows when to show: Are you still watching? Is it just time-based?
If it were time-based, you would see it every time.
So what is actually going on under the hood?
Both look like a simple pop-up. Underneath, it is a mix of product thinking, client logic, and backend events.
Btw, if you’re preparing for system design/coding interviews, check out our mock interview tool. You can use it for free here: https://lnkd.in/gpCn7t2T
[1] Start from the product goals
The feature is not only about nagging people.
- Save bandwidth and CDN cost if the viewer has slept or walked away
- Avoid autoplaying potentially sensitive content in an empty room
- Protect kids if parents start a show and leave the TV on
- Do all this without annoying active binge watchers
So the design must answer one question: "When is the user probably not here any more"
[2] Naive design - pure timer
Simplest idea:
- If playback has been running for 2 hours, show Are you still watching
- If user clicks "Yes", reset the timer
Why this is weak:
- Someone can binge 5 episodes in a row and gets interrupted in the middle of an intense scene
- Someone can start a show, walk away after 5 minutes, and the platform will keep streaming for the next 2 hours
- It ignores how many episodes were auto played, device type, time of day, user habits
[3] Realistic design - session and engagement signals
Think in terms of a "watch session" and "engagement events".
Signals the client can track:
- Play, pause, seek, volume change
- Episode finished and next episode auto started
- Remote or keyboard input, UI navigation
- Screen on or off events from the device
- For mobiles: app background or locked state
A common heuristic could be:
- Count how many episodes have auto played without any user interaction
- Track how long it has been since the last button press or navigation
- Only trigger the prompt when both are high enough
Example rule:
- If 3 episodes in a row have auto played
- And there has been no interaction for 45 minutes
- Then, before starting episode 4, show Are you still watching
This feels much smarter:
- Active viewers who pause, skip intro, change volume keep resetting the "engagement clock"
- Sleeping viewers do not touch anything, so the next episode is blocked by the prompt
[4] Client heavy vs server heavy design
You can talk about two design choices.
Client first:
- All logic runs inside the app on TV, mobile, or web
- Client keeps an in memory session model and decides when to show the popup
- It still sends telemetry events to backend for analytics and future tuning
Pros:
- Works even with flaky network
- Highly responsive, no extra server round trip
Cons:
- Logic must be implemented and updated across many platforms
- Harder to quickly roll out rule changes
Continued ↓