How Notion Works Under the Hood

Notion feels simple. You type. Blocks move around. Someone else edits the same page and you see it instantly. It looks like magic, but everything is built on a few very real engineering ideas that make the experience smooth, fast and collaborative.

Let’s walk through how the whole machine works, starting from the moment you hit a key on your keyboard to the moment your text appears in the database and on someone else’s screen.

I’ll keep it simple enough that even a fresher will get the complete picture, without losing the technical reality behind it.

Everything in Notion Is a Block

When you type in Notion, you are not writing into a big text file. Notion breaks everything into blocks. A paragraph is a block. A heading is a block. An image is a block. A list item is a block. Each block carries its own unique id, type, content, styling information and position inside the page.

Think of a Notion page as a tree. The page itself is the root, and every block inside it is a branch or leaf. Some blocks can have children, like a toggle list that contains paragraphs inside it. Because of this tree structure, Notion can update or rearrange only the parts that actually changed instead of redrawing the entire page.

How Real Time Collaboration Actually Works

This is where most people imagine some kind of magic. Multiple users typing at the same time could easily turn into a mess. Instead, Notion uses CRDTs, which stands for Conflict Free Replicated Data Types. You don’t need to know the math behind it. All you need to understand is that CRDTs guarantee that even if three people type at the same time, or even if someone goes offline and comes back later, all edits can be merged automatically without conflicts.

Every time you type a character, your browser creates something called an operation. This is just a tiny description of what changed. For example, “insert the letter A in block 21 at position 5”. This single operation is enough for another user to replicate your change.

Your browser applies the change instantly. It does not wait for the server. That is why typing feels immediate. Then this same operation is sent through a WebSocket to the server.

Google Docs uses a different technique called Operational Transform or OT. OT also merges concurrent edits, but it requires a central server to adjust operations when conflicts occur. CRDTs don’t need a central referee, which is why tools like Notion, Figma and Miro use them. They work online, offline and in any order without breaking.

This is the entire secret behind Notion's real time collaboration.

What WebSockets Do in This System

A WebSocket is simply a permanent connection between your browser and the server. It is not like a normal request where you send something and the connection closes. A WebSocket stays open as long as the page is open. Because of this, the server can send you updates immediately, and you can send updates just as fast.

When you type something, your browser sends the operation through the WebSocket. The server receives it, checks if it is valid, and then broadcasts that operation to every other connected user who is viewing the same page.

Everyone else receives the same operation and applies it to their copy of the document. CRDT rules make sure the ordering of changes is always correct, even if they arrive slightly out of order.

That is why Notion collaboration feels instant, predictable, and conflict free.

How the Operation Reaches the Database

When the server receives the operation from your browser, it does two important jobs.

First, it saves the operation itself into an Operations table in the database. This table stores every tiny edit ever made to the page. This helps with undo and redo, version history and reconstructing a full page if needed.

Second, it updates the current block in the Blocks table. This table represents the current state of every block in the document. It is used when someone opens a page so they can see the latest version without replaying thousands of operations.

After a certain number of operations, the server creates a snapshot. A snapshot is basically a full copy of the page at that moment. This makes loading very large pages much faster in the future.

So the full storage system is made of three things: blocks, operations and snapshots. Blocks store the current state. Operations store the changes. Snapshots store checkpoints.

How the UI Fetches Data From the Database and Stays in Sync

When you open a Notion page, the browser does not load operations. It loads the latest snapshot and the current block data. This gives you the entire page structure instantly.

At the same time, your browser opens a WebSocket connection to the server. Now the server can send you new operations the moment they happen. If another user edits the page, the server immediately pushes the corresponding operation to your browser.

Your browser applies the operation, updates the CRDT state, and React re renders only the block that changed. You never see flicker or reload because only the affected section updates.

This is how the UI stays in sync. It is a mix of fast reads from snapshot and block tables, plus continuous live updates from the WebSocket.

What Happens If Your Internet Dies While Editing

Nothing breaks. Nothing freezes. Nothing disappears.

Your browser simply keeps generating operations and stores them in its own local storage, usually IndexedDB. CRDT allows your edits to be applied locally even without server approval. When the network comes back, your browser pushes all pending operations to the server. The server merges them with the existing document and sends updates to other users.

The result is the same document for everyone, regardless of timing.

What Technologies Does Notion Use Behind the Scenes

People often imagine Notion as a simple React app with some clever styling on top. The truth is a little more interesting. Notion uses React on the frontend, but the heart of the system is powered by a combination of real time networking, efficient data modeling and some smart performance choices.

The editor runs on React, but with heavy custom logic for rendering blocks, handling selection, managing the caret, drag and drop and dealing with CRDT merging. They rely on WebSockets for live updates, so every user sees changes the moment they happen. For storing data, Notion uses Postgres as the main database, with Redis for fast caching and job queues. On the backend side, much of their business logic is built with TypeScript and Node based services. They also use Rust in performance critical areas, especially for their CRDT implementation and anything that needs to handle large documents with low latency.

Search runs on specialized indexing systems. Media uploads are stored in cloud storage. Real time presence and collaboration run on a custom service built on top of WebSockets.

The short version is that Notion mixes React, CRDTs, WebSockets, Node, Rust, Postgres, and a set of highly optimized internal systems that make the whole thing feel smooth even when thousands of operations are flying around.

Putting It All Together, Step by Step

Here is the complete flow in plain English.

You type a letter.
Your browser updates the block instantly.
It creates an operation that describes your edit.
The operation goes through the WebSocket to the server.
The server stores the operation.
The server updates the block’s current state.
The server broadcasts the operation to every other user.
Other users apply the operation to their copy of the page.
React re renders only the changed block.
Everyone sees the same result.
Snapshots are created periodically for performance.
If you go offline, edits stay local and sync later.

This is the entire engine behind Notion’s real time collaboration.

Final Thoughts

Building a Notion like editor is incredibly hard. The team has blended clever data modeling, realtime networking, conflict free algorithms, background syncing and smart rendering into a single system that behaves exactly the way humans expect.

The beautiful part is that once you understand blocks, operations, WebSockets, CRDT merging and the three layer database model, the whole system actually becomes clear.

If you want, I can now help you write a version of this for LinkedIn, or prepare an interview style answer that will make you sound completely prepared.