How Does Notion Keep Your Phone and Laptop in Sync?

I was using Notion on my phone.

My laptop had the exact same page open.

I changed a sentence on my phone.

A few moments later...

The laptop changed too.

I didn't refresh the page.

I didn't press save.

I didn't send anything manually.

It just happened.

Which made me wonder:

How does Notion actually keep two completely different devices looking at the same document?

Because there isn't really a "Notion file" sitting on your laptop.

There are multiple copies of the same data...

And Notion has to keep them consistent.

There Isn't One Document

The first thing to understand is that your phone and laptop aren't constantly looking at the same local file.

Think about it more like this:

                 Notion Cloud
                      |
             ┌────────┴────────┐
             ↓                 ↓
          Laptop             Phone
        Local State         Local State

Both devices maintain their own local representation of the page.

The cloud acts as the shared source of truth.

When you edit something, your device sends the change to Notion's servers.

The server processes it and other connected clients learn about the update.

So What Happens When I Type?

Suppose your page says:

I love distributed systems.

You change it on your phone:

I love distributed systems and coffee.

Conceptually, something like this happens:

Phone
 
User types
 
↓
 
Local state changes immediately
 
↓
 
Change sent to Notion
 
↓
 
Server processes update
 
↓
 
Update published
 
↓
 
Laptop receives update
 
↓
 
Laptop updates its local state

The important detail is that your phone doesn't wait for the server before showing your typing.

That would feel terrible.

Instead, modern collaborative applications generally make local interactions feel immediate and synchronize them in the background.

The Secret: Local State

Imagine every device has a local copy.

Laptop
┌─────────────────────┐
│ I love distributed  │
│ systems.            │
└─────────────────────┘
 
Phone
┌─────────────────────┐
│ I love distributed  │
│ systems.            │
└─────────────────────┘

You edit your phone:

I love distributed systems and coffee.

The phone immediately updates its own state.

At the same time:

Phone
   |
   | change
   ↓
Notion Server
   |
   | update
   ↓
Laptop

This is why the UI feels instant.

But How Does The Laptop Know Something Changed?

This is where real-time communication becomes interesting.

You could build a primitive version using polling:

Laptop:
 
"Anything new?"
 
↓
 
Server:
 
"No."
 
↓
 
Laptop:
 
"Anything new?"
 
↓
 
Server:
 
"No."
 
↓
 
Laptop:
 
"Anything new?"
 
...

This works.

But it's wasteful.

Imagine millions of devices doing this every few seconds.

That's an enormous number of unnecessary requests.

Modern systems instead use push-based updates for real-time behavior.

Notion has specifically described using push-based updates for offline pages: when a batch of updates is applied to a page, the server emits a message on a channel for that page, and subscribed clients can then fetch the latest changes.

Conceptually:

                  Notion Server
                       |
                 Page Update
                       |
                       ▼
               Update Channel
                 /         \
                /           \
               ▼             ▼
           Laptop           Phone

The server doesn't need to repeatedly ask:

"Do you have anything new?"

It can tell interested clients when something changed.

WebSockets Are One Way To Do This

A common technology for this kind of real-time communication is a WebSocket.

Instead of:

Request
  ↓
Response
  ↓
Connection closes

you maintain a persistent connection:

Laptop
   │
   │══════════════════╗
   │                  ║
   │     WebSocket    ║
   │                  ║
   ╚══════════════════║
                      ↓
                  Server

Now the server can push information to the client when something happens.

For example:

Page updated
 
↓
 
Server
 
↓
 
"Page 123 changed"
 
↓
 
Laptop receives event
 
↓
 
Fetch/apply update

The exact transport and implementation details inside Notion aren't all publicly documented, so it's better to think of WebSockets as a common implementation pattern rather than claim that every part of Notion's system uses WebSockets.

But There Is A Bigger Problem

Imagine this.

Your phone edits:

Hello world

At exactly the same time...

Your laptop edits the same page:

Hello Notion

Now what?

Two devices.

Two changes.

One document.

Welcome to conflict resolution.

Distributed Systems Problem #1: Conflicts

Consider:

                 Page
                  |
          ┌───────┴───────┐
          ↓               ↓
        Phone           Laptop
          |               |
      Edit A           Edit B
          |               |
          └───────┬───────┘
                  ↓
              Server
                  |
                  ?

Which change wins?

If you simply use:

last write wins

you could accidentally overwrite somebody else's work.

For simple applications, that's sometimes acceptable.

For a collaborative editor...

Not really.

Notion's Block Architecture Makes This Interesting

Notion doesn't treat a page like one giant text file.

A page is composed of blocks.

For example:

Page
│
├── Heading
├── Paragraph
├── Image
├── Database
├── Todo
└── Callout

This gives the system more granular pieces to work with.

Instead of thinking:

Entire Page Changed

you can reason about:

Block A changed
Block B moved
Block C was deleted

This becomes extremely important when synchronizing complex documents.

Notion has publicly discussed how its block architecture created significant challenges around reference tracking, background syncing, and rich-text conflict resolution when building offline support.

CRDTs Enter The Picture

Notion has also described migrating offline-capable pages to a CRDT-based data model.

CRDT stands for:

Conflict-free Replicated Data Type.

The basic idea is fascinating.

Multiple copies of data can be modified independently.

Later, those changes can be merged in a deterministic way.

Conceptually:

             Shared Document
                    |
        ┌───────────┴───────────┐
        ↓                       ↓
      Phone                   Laptop
        |                       |
     Edit A                   Edit B
        |                       |
        └───────────┬───────────┘
                    ↓
                  Merge
                    ↓
             Consistent State

Instead of saying:

"Only one device can edit at a time."

the system is designed to deal with concurrent changes.

That's a much more interesting distributed-systems problem.

Offline Sync Makes It Even Harder

Now imagine:

You take your phone on a flight.

No internet.

You edit your Notion page.

At the same time...

Someone edits the same page on your laptop.

Your phone doesn't know about their change.

             Page
               |
       ┌───────┴────────┐
       ↓                ↓
     Phone            Laptop
       |                |
   Offline           Online
       |                |
    Edit A            Edit B
       |                |
       X                |
   No network           |
       |                |
       └───────┬────────┘
               ↓
          Reconnect
               ↓
        Conflict Resolution

This is much harder than simple real-time syncing.

Notion's engineering team says its offline architecture uses persistent local storage, background syncing, push-based updates, and a CRDT data model to handle these cases.

Local Storage Matters Too

Your phone can't rely entirely on the cloud.

If you're offline, it still needs to display and edit the page.

Notion says its apps use SQLite as part of their local storage architecture, and its offline work evolved that cache into a persistent storage layer capable of tracking which pages are available offline and storing the data needed to render them.

So the architecture starts looking like:

                  Notion Cloud
                       |
          ┌────────────┴────────────┐
          ↓                         ↓
      Laptop                     Phone
          |                         |
       SQLite                    SQLite
          |                         |
     Local State               Local State

Each device can work with its local data.

The synchronization layer keeps bringing those replicas back toward consistency.

What Happens When You Reconnect?

Suppose your phone was offline for three hours.

It doesn't necessarily need to download the entire page again.

Notion says clients track a lastDownloadedTimestamp for offline pages. When reconnecting, the client can compare that timestamp with the server's latest update time and fetch pages whose server version is newer.

Conceptually:

Phone:
 
Last synced:
10:00 AM
 
Server:
 
Last updated:
1:00 PM

The client knows:

Something changed.

So it catches up.

10:00 AM
    |
    | missed changes
    |
    ▼
1:00 PM

This is much more efficient than:

Download everything again.

Why Doesn't It Constantly Download The Entire Page?

Because that would be ridiculous at scale.

Imagine a user has:

10,000 pages

and edits one paragraph.

You don't want:

10,000 pages
       ↓
Download everything

You want:

One change
    ↓
Small update
    ↓
Apply locally

This is the general principle behind incremental synchronization.

Only synchronize what actually changed whenever possible.

The Architecture

Putting everything together:

                         Notion Cloud
                              |
                    ┌─────────┴─────────┐
                    │                   │
              Update Processing     Storage
                    │                   │
                    └─────────┬─────────┘
                              │
                       Push Update
                              │
              ┌───────────────┴───────────────┐
              ↓                               ↓
           Laptop                           Phone
              │                               │
          Local DB                         Local DB
              │                               │
          Local State                     Local State
              │                               │
              └────────── Sync ───────────────┘

And when devices are offline:

Device
  |
  ├── Read local data
  ├── Apply local edits
  └── Queue changes
 
          ↓ reconnect
 
       Sync Engine
 
          ↓
 
     Conflict Resolution
 
          ↓
 
     Consistent State

The Beautiful Part

The thing that looks like:

"I changed something on my phone and it appeared on my laptop."

is actually a combination of several difficult engineering problems:

Local persistence

Store enough data locally to make the application usable.

Change propagation

Get updates from the server to connected clients.

Incremental synchronization

Transfer only what changed instead of everything.

Conflict resolution

Handle multiple devices modifying the same data.

Consistency

Eventually bring different replicas toward the same state.

Offline support

Allow changes to happen without a network connection.

This Pattern Exists Everywhere

Notion isn't special in this regard.

You'll find variations of the same ideas in:

• Google Docs
• Figma
• GitHub Codespaces
• Slack
• Dropbox
• OneDrive
• Linear
• collaborative IDEs
• multiplayer games

Whenever the same piece of data exists in multiple places...

you have a synchronization problem.

And synchronization is fundamentally a distributed systems problem.

Final Thoughts

The next time you edit a Notion page on your phone and watch your laptop update almost instantly...

don't think:

"The app refreshed."

Think:

Local State
    ↓
Change
    ↓
Server
    ↓
Update Propagation
    ↓
Other Replica
    ↓
Consistent State

Two devices.

Two local copies.

One shared document.

And an enormous amount of engineering making them feel like one thing.

That's the magic of synchronization.

The hardest part of making two computers share data isn't sending the data.

It's deciding what the data should mean when both computers changed it.