How Netflix Remembers Exactly Where You Stopped Watching

Imagine you're watching Stranger Things on your TV.

You stop at:

Season 2
 
Episode 5
 
32:14

You leave home.

Open Netflix on your phone.

A second later...

Continue Watching
 
32:14

appears.

You never refreshed anything.

You never clicked Sync.

So how did Netflix know exactly where you stopped?

Surely it isn't just Local Storage.

The Naive Solution

A beginner might think:

Video Player
 
↓
 
Save Current Time
 
↓
 
Local Storage

This works...

Until you open another device.

Your TV has one local storage.

Your phone has another.

Your laptop has another.

None of them can talk to each other.

If Netflix relied only on local storage, every device would start from the beginning.

Clearly something else is happening.

Every Device Talks To The Backend

Instead of storing progress only on the device...

Netflix also stores it on the server.

A simplified flow looks like this.

TV
 
↓
 
Playback Service
 
↓
 
Database

Whenever you pause, close the app, or reach a checkpoint...

The player sends something like:

POST /playback
 
{
  "userId": 101,
  "videoId": 845,
  "position": 1934
}

The backend now knows:

• Who is watching.
• Which title.
• Exactly where they stopped.

But Updating Every Second Would Be Terrible

Suppose Netflix saved your progress every second.

A two-hour movie contains:

7200 Seconds

That would generate:

7200 Database Writes
 
For One User

Now imagine:

100 Million Users

The database would spend its entire life updating timestamps.

Clearly this doesn't scale.

Smart Checkpoints

Instead, Netflix updates progress intelligently.

For example:

• Every 15–30 seconds.
• When you pause.
• When you close the app.
• When playback finishes.

The backend receives far fewer updates while keeping progress accurate enough for users.

Losing two seconds of playback is acceptable.

Overloading the database isn't.

What Happens When You Switch Devices?

Now imagine this.

You pause on your TV.

Five seconds later...

Open Netflix on your phone.

The phone simply asks:

GET /continue-watching
 
userId=101

The backend responds:

{
  "videoId":845,
  "position":1934
}

The player immediately seeks to:

32:14

From the user's perspective...

It feels like magic.

In reality...

Every device is reading from the same source of truth.

Why Doesn't Netflix Query The Database Every Time?

Imagine millions of users opening the app simultaneously.

Fetching playback progress directly from the database every time would create enormous load.

Instead...

Frequently accessed data is often cached.

Phone
 
↓
 
Playback Service
 
↓
 
Redis
 
↓
 
Database

If the progress already exists in Redis...

The response arrives in milliseconds.

The database isn't touched.

What If Two Devices Play At The Same Time?

Suppose you're watching on your TV.

Someone else opens the same profile on a tablet.

Both devices now update progress.

Which one should Netflix keep?

A common approach is:

Latest Timestamp Wins

If the tablet reports:

45:12

after the TV reported:

42:08

the newer update becomes the latest resume point.

In practice, systems also consider playback state and timestamps to avoid older updates overwriting newer ones.

Continue Watching Isn't Just One Number

Netflix stores more than:

32:14

It also tracks information like:

• Episode number.
• Season.
• Completion percentage.
• Whether credits started.
• Last watched time.

This allows Netflix to know whether to:

• Resume the current episode.
• Start the next episode.
• Remove the title from Continue Watching.

Event-Driven Updates

Saving playback progress doesn't only affect one service.

When progress changes...

Other systems may also care.

Playback Updated
 
↓
 
Recommendations
 
↓
 
Continue Watching
 
↓
 
Analytics
 
↓
 
Viewing History

Instead of calling every service directly...

The playback service can publish an event.

Each downstream service reacts independently.

This keeps the architecture loosely coupled and easier to scale.

What Happens If The Network Goes Down?

Suppose you're watching on a flight.

No internet.

Should Netflix stop remembering your progress?

Of course not.

The app temporarily stores playback progress locally.

When the connection returns...

Pending updates are synchronized with the backend.

This allows offline playback without losing your place.

Follow-Up Questions Interviewers Love

Why not use only Local Storage?

Local storage exists only on one device.

Users expect playback progress to follow them across TVs, phones, tablets, and laptops.

Why not update the database every second?

Millions of users writing every second would overwhelm the database.

Periodic checkpoints provide a much better balance between accuracy and scalability.

Why use Redis?

Playback progress is read frequently and changes relatively often.

Caching reduces latency and protects the primary database from excessive reads.

Why publish events?

Multiple services need playback information.

Event-driven architecture allows each service to react independently without tightly coupling the system.

Lessons Beyond Netflix

The same synchronization pattern appears everywhere.

• Spotify syncing playback across devices.
• YouTube remembering watch history.
• Kindle remembering your last page.
• Google Docs saving your cursor position.
• Online games synchronizing player progress.

Different products.

The same distributed systems problem.

Final Thoughts

The "Continue Watching" button looks simple.

But behind it is a carefully designed system balancing consistency, scalability, and user experience.

Netflix doesn't rely on local storage alone.

It continuously synchronizes playback across devices, caches frequently accessed data, batches updates to reduce database load, and uses event-driven architecture so multiple services stay in sync.

The next time you pause a movie on your TV and resume it on your phone...

Remember that you're not just watching a video.

You're interacting with a distributed system that quietly keeps your experience seamless, no matter which device you pick up next.