Modern Netflix subscribers don't watch on one device—they flow seamlessly between smart TVs, phones, tablets, laptops, and gaming consoles. The experience must feel unified: pause on your phone during commute, resume on your TV at home. Add a show to your watchlist on your laptop, see it immediately on your tablet.

This seamless multi-device experience requires sophisticated distributed state management. Every piece of user state—viewing progress, watchlists, preferences, playback settings—must be synchronized across all devices in near-real-time while handling the inherent challenges of distributed systems: network partitions, concurrent updates, offline devices, and eventual consistency.

Netflix must also enforce subscription constraints: concurrent stream limits, device registration limits, and regional access controls. The same infrastructure that enables seamless sync must also enforce business rules.

This page explores the complete multi-device synchronization architecture—from the data model through sync protocols to conflict resolution and concurrent stream management.

Not all state is equal. Different types of data have different consistency requirements, update frequencies, and tolerance for staleness. Netflix categorizes state to apply appropriate sync strategies.

State Ownership Model:

Netflix uses a hierarchical ownership model:

Account
├── Subscription (billing, plan, limits)
├── Device Registrations (devices allowed to stream/download)
└── Profiles (up to 5 per account)
    ├── Viewing History (per profile)
    ├── Watchlist (per profile)
    ├── Playback Progress (per profile, per title)
    ├── Preferences (subtitle, audio, maturity)
    └── Recommendations (computed from history)

Each profile is independent—watching on Profile A doesn't affect Profile B's recommendations. This separation simplifies sync (per-profile state is isolated) but creates complexity (must track which profile is active on each device).

Netflix's sync architecture combines event-driven updates with periodic polling to balance consistency guarantees with system efficiency.

Data Store Selection:

Cassandra for User State:

• High write throughput for playback progress updates
• Tunable consistency (can use QUORUM for critical writes)
• Natural partitioning by user ID
• Multi-region replication for global availability

EVCache for Read Acceleration:

• Sub-millisecond reads for common state (preferences, recent history)
• Reduces Cassandra read load by 90%+
• Eventual consistency acceptable for cached data

Real-Time Store for Sessions:

• ZooKeeper or Redis-based for active session tracking
• Strong consistency needed for stream count enforcement
• Lower scale (only active sessions, not historical)

Kafka for Event Distribution:

• Decouples state writes from notification delivery
• Enables multiple consumers (push service, analytics, recommendations)
• Replay capability for debugging and recovery

Playback progress sync is the most visible sync feature—the magic of pausing on one device and resuming on another. The implementation must handle high write volume while providing a seamless user experience.

Progress Update Strategy:

Netflix doesn't report every frame. Instead:

Progress Update Triggers:
├── Playback start (position 0 or resumed position)
├── Every 60 seconds during playback
├── On pause event
├── On seek completion
├── On playback stop/exit
└── On playback completion (marks title as 'watched')

Data Model:

ViewingProgress {
  profileId: string
  titleId: string
  position: number (seconds)
  runtime: number (total duration)
  percentComplete: number
  lastWatched: timestamp
  state: 'watching' | 'paused' | 'completed' | 'abandoned'
  deviceId: string (which device)
}

Last-Writer-Wins with Timestamp:

When two devices report progress for same title:

1. Each update includes client timestamp (wall clock when position reached)
2. Server stores only the most recent update by timestamp
3. If timestamps are close (within 30 seconds), server picks higher position (assumes one device is slightly behind)

Device A reports: position=1800, timestamp=T1
Device B reports: position=900, timestamp=T2

If T2 > T1: Keep position=900 (B is more recent)
If T1 > T2: Keep position=1800 (A is more recent)
If T1 ≈ T2: Keep position=1800 (max position wins)

Edge Cases:

Netflix subscription plans include concurrent stream limits (1-4 streams depending on plan). Enforcing these limits accurately at global scale is a significant distributed systems challenge.

Session Tracking Architecture:

Stream Session {
  accountId: string
  profileId: string
  deviceId: string
  titleId: string
  startTime: timestamp
  lastHeartbeat: timestamp
  region: string (for licensing)
}

Heartbeat Mechanism:

1. Stream Start — Register session with central coordinator
2. During Playback — Client sends heartbeat every 60-120 seconds
3. Stream End — Client sends explicit 'stop' event, session removed
4. Heartbeat Timeout — If no heartbeat for 5 minutes, session considered dead and garbage collected

Enforcement Flow:

[Play Button Pressed]
     ↓
[Query Active Sessions for Account]
     ↓
[Count < Limit?] ──No──→ [Block with Error Message]
     ↓ Yes
[Register New Session]
     ↓
[Begin Playback]
     ↓
[Heartbeat Loop]
     ↓
[Stop/Timeout]
     ↓
[Deregister Session]

Handling Race Conditions:

Two devices press play simultaneously:

1. Both reach 'Query Active Sessions'
2. Both see count = 1, limit = 2 (1 available slot)
3. Both try to register

Solution: Atomic Compare-And-Swap

• Use conditional write: 'Add session if current count < limit'
• Only one succeeds atomically
• Loser receives conflict response, retries, sees limit reached

Distributed Implementation:

• Sessions stored in Redis Cluster or custom distributed store
• Hash by account ID to single node for each account
• All session operations for one account go to same node
• Eliminates distributed transaction complexity

Regional Considerations:

• Session tracking is global (account-level limit)
• But check can be regional: query local Redis, async replicate to others
• Accept slight over-provisioning (2-3 extra streams briefly) for latency
• Periodic tight reconciliation catches abuse

The watchlist ('My List') is user-curated content. Unlike playback progress (system-generated), watchlist changes are explicit user actions that demand immediate, visible feedback.

Watchlist Data Model:

WatchlistEntry {
  profileId: string
  titleId: string
  addedAt: timestamp
  position: number (for custom ordering)
  source: 'manual' | 'recommended'
}

CRDT-Inspired Design:

Netflix's watchlist uses a design inspired by Conflict-free Replicated Data Types (CRDTs):

Add-Wins Semantics:

• If one device adds and another removes simultaneously, add wins
• Rationale: User who added wanted to watch; removal might have been accidental
• Implementation: Track 'add' and 'remove' events separately; add timestamp > remove timestamp means present

Tombstones:

• Removed items aren't deleted, they're marked as removed with timestamp
• Allows comparison with add events across devices
• Periodically garbage-collect old tombstones (> 30 days)

Ordering:

• Each item has position (0 = top of list)
• On add, assign position = 0, shift others down
• On reorder, update positions of affected items
• Conflicts: use add timestamp to order items added simultaneously

Sync Protocol:

[User adds title X]
     ↓
[Optimistic local update → UI shows X immediately]
     ↓
[Send to server: addToWatchlist(profileId, titleId, timestamp)]
     ↓
[Server applies, publishes event to Kafka]
     ↓
[Other devices receive push notification]
     ↓
[Other devices update local watchlist]

Handling Offline:

• If add happens offline, queued locally
• On reconnection, sends queued changes with original timestamp
• Server merges based on timestamps
• May result in 'surprise' items appearing if offline-added items had old timestamps

Netflix tracks devices associated with accounts for both feature enablement (downloads) and security (unusual device detection, remote sign-out).

Device Identity:

Each device is assigned a unique device ID:

DeviceRecord {
  deviceId: string (unique identifier)
  accountId: string
  deviceType: 'tv' | 'phone' | 'tablet' | 'computer' | 'game-console'
  deviceName: string (e.g., 'John's iPhone 14')
  firstSeen: timestamp
  lastActive: timestamp
  downloadEnabled: boolean
  region: string (geo of last access)
  appVersion: string
}

Device ID Generation:

Device IDs must be stable across app restarts but unique per device:

• iOS: Use IdentifierForVendor (consistent for same developer's apps)
• Android: Use Android ID + app-specific salt
• Web Browsers: Generate UUID, store in secure cookie/localStorage
• Smart TVs: Use device serial number or generated ID stored on device

Device Limit Enforcement:

[User requests download on Device D]
     ↓
[Query: count of download-enabled devices for account]
     ↓
[Count >= limit?]
     ↓ Yes
[Prompt: 'Remove a device to enable downloads here']
     ↓
[User removes device or gives up]

Remote Sign-Out:

When user triggers 'Sign out all devices':

1. Invalidate all refresh tokens for account
2. Publish 'force-logout' event to all device registrations
3. Connected devices receive push, clear local auth
4. Devices not connected will fail on next API call (token invalid)
5. Downloaded content remains (can't remotely wipe), but can't play (no valid session)

Household vs Account Sharing:

Netflix has been cracking down on password sharing. Device tracking enables detection:

• Multiple devices in different geographic regions
• Devices on networks not associated with billing address
• Unusual access patterns (simultaneous viewing from distant locations)

Enforcement can prompt verification ('Is this your device?') or require additional subscriber fees.

Push-based real-time updates are what make multi-device sync feel magical. The infrastructure to deliver updates to millions of connected devices reliably and quickly is complex.

Connection Management at Scale:

Millions of concurrent WebSocket connections require specialized infrastructure:

Connection Servers:

• Stateless edge servers handle WebSocket connections
• Each server handles 50,000-100,000 connections
• Connections are load-balanced but sticky (same client reconnects to same or equivalent server)

Connection Registry:

• Central registry tracks which connection server each user is connected to
• When event needs to reach user, lookup registry, route to correct server
• Registry must handle millions of entries with fast lookup and update

Message Routing:

[State Change Event (Kafka)]
     ↓
[Push Service Consumer]
     ↓
[Lookup: which connection server has this user?]
     ↓
[Route message to that server via internal channel]
     ↓
[Connection Server delivers via WebSocket]
     ↓
[Client receives update]

Scalability Pattern: Fan-out Write vs Fan-out Read

Write-Time Fan-out:

• On state change, immediately send to all user's devices
• Pro: Instant delivery, simple client
• Con: Expensive if user has many devices or many updates

Read-Time Fan-out:

• On state change, mark user as 'dirty'
• When device polls/connects, check if dirty, fetch latest state
• Pro: Efficient if many updates between reads
• Con: Delays update delivery

Netflix Hybrid:

• Real-time push for connected devices (write-time)
• On reconnection, fetch full state (handles missed messages)
• Critical updates (force logout) use aggressive retry

Multi-device synchronization at Netflix scale embodies core distributed systems principles. The patterns used apply to any system requiring real-time state sync across devices.