Concepts
Multi-Device Sync
The model that lets one account use several devices while keeping messages, cursors, receipts, and local state coherent.
Concepts Covered
- Device identity
- Per-device sync cursors
- Account-level state
- Multi-device delivery
- Read state propagation
- Conflict handling
- Device-specific acknowledgements
- Local versus shared state
Definition
Multi-device sync is the set of rules and data models that let one user operate the same account across multiple devices.
The product expectation is simple: a user sends a message from their phone, sees it on their laptop, reads a conversation on their tablet, and expects the unread count to make sense everywhere.
The engineering reality is harder because each device has its own connection state, local cache, network quality, notification token, and sync progress.
A serious design needs to distinguish user-level state from device-level state.
The Pain That Forces Multi-Device Modeling
If a system only thinks in users, it quickly becomes confused.
Suppose user u_7 has three devices:
phone: connected
laptop: offline
tablet: connected but stale
If the system stores only:
user_7 has received message m_9
it cannot answer whether the laptop still needs to sync that message later.
If the system stores only:
user_7 is online
it may forget that the laptop is offline and still needs push or future sync.
Multi-device systems need explicit device identity and per-device progress.
Mental Model
One account does not mean one connection, one cursor, or one device state.
A better model separates:
user identity: who owns the account
device identity: which installed client is syncing
connection identity: which live socket exists right now
sync cursor: how far this device has caught up
This lets each device recover independently while still sharing account-level truth.
Per-Device Cursors
Per-device state is precise:
device_id -> last_received_sequence
d_phone -> 84211
d_laptop -> 83990
d_tablet -> 84100
When the laptop reconnects, it does not need to guess based on what the phone saw. It asks for the messages after its own cursor.
This matters because devices can be offline for different lengths of time.
User-Level Versus Device-Level State
Some state belongs to the account:
- conversation membership
- profile identity
- block or privacy settings
- account-level read position, depending on product rules
- archive, mute, or pinned state if the product treats them as shared
Other state may be device-level:
- last synced sequence
- local media download state
- device notification token
- device presence
- device-specific delivery acknowledgement
- local drafts or unsent messages
The product must choose which settings sync globally and which stay local.
Send From One Device, Show On Another
When a user sends a message from the phone, the laptop should eventually see that outbound message too.
There are two common approaches:
- Treat the sender's other devices like recipients.
- Let every device sync from the conversation log using cursors.
The first approach makes active devices update quickly. The second gives a durable recovery path. Most robust designs need both realtime fan-out and cursor-based sync.
Read State Across Devices
Read state is subtle.
If the user reads a conversation on the laptop, should the phone stop showing it as unread? Usually yes, but exact behavior depends on product rules.
A common model stores a user-level read cursor:
user_id + conversation_id -> read_up_to_sequence
Each device can also have local state for what it has downloaded or displayed. This separation lets the user-level unread count converge while devices still sync independently.
Operational Reality
Important signals:
- device registration count per user
- sync lag per device
- cursor advancement failures
- duplicate outbound sends by device
- notification token churn
- read-state propagation latency
- devices stuck behind retention windows
- conflicts between local and account-level settings
Failure modes:
- A message appears on one device but never syncs to another.
- Read state clears on one device but remains stale on another.
- One device sends a retry that creates a duplicate because idempotency is scoped incorrectly.
- Notification tokens are treated as user-level instead of device-level.
- Presence says the user is online but the target device is not reachable.
- Local-only state is accidentally overwritten by account-wide sync.
Related Topics
Knowledge links
Use these links to understand what to know first, where this idea appears, and what to study next.
Prerequisites
Read these first if this topic feels unfamiliar.
Used In Systems
System studies where this idea appears in context.
Related Concepts
Core ideas that connect to this topic.
Related Patterns
Reusable architecture moves built from these ideas.