TC
productivity7 min read

Real-Time Collaboration: How P2P Sync Works Without a Server

How can two people edit the same document at the same time, from different continents, without a server in between? The answer involves a clever combination of direct browser-to-browser connections, conflict-free data structures, and a tiny bit of coordination. Here's how peer-to-peer collaboration actually works.


What “peer-to-peer” really means

In a traditional web app, every action goes through a central server. You type a message, it flies to a data center, gets stored, and then gets pushed to other users. The server is the single source of truth.

In a peer-to-peer (P2P) architecture, there is no central server holding your data. Instead, your browser connects directly to other browsers. Changes are sent straight from one user to another. The data lives on the devices of the people using it — nowhere else.

Privacy implication: In a P2P system, your data never touches a third-party server. There is no database to breach, no company storing your notes. The trade-off is that if all devices go offline or are lost, the data is gone.

The merge problem: why collaboration is hard

Imagine two people editing a shared to-do list at the same time. Alice adds “Buy milk” while Bob deletes item #3. Without coordination, these changes can conflict — the list can end up in different states on different devices.

Traditional databases solve this with locks: only one person can write at a time. But locks require a central authority (the server). In P2P, there is no central authority. So how do you merge changes without conflicts?

CRDTs: conflict-free by design

CRDTs (Conflict-free Replicated Data Types) are data structures mathematically guaranteed to merge without conflicts. No matter what order changes arrive in, every peer converges to the same state. This property is called eventual consistency.

How CRDTs work (simplified)

A CRDT doesn't store “the current value.” It stores a log of operations, each tagged with a unique ID and a logical timestamp. When two peers sync, they exchange operations they haven't seen yet. The merge function is designed so that:

  • Commutative — order doesn't matter. A + B = B + A
  • Idempotent — applying the same operation twice has no extra effect
  • Associative — grouping doesn't matter. (A + B) + C = A + (B + C)

The Yjs library is one of the most popular CRDT implementations for JavaScript. It provides shared types like Y.Array, Y.Map, and Y.Text that behave like normal JavaScript objects but sync automatically across peers.

// Creating a shared document with Yjs
import * as Y from 'yjs'

const doc = new Y.Doc()
const todos = doc.getArray('todos')

// Adding an item — automatically syncs to all peers
const item = new Y.Map()
item.set('text', 'Buy milk')
item.set('done', false)
todos.push([item])

// Observing changes from any peer
todos.observe(event => {
  console.log('Todos changed:', todos.toArray())
})

WebRTC: browser-to-browser connections

WebRTC (Web Real-Time Communication) is a browser API originally built for video calls. It creates direct, encrypted connections between browsers without data passing through a server. P2P collaboration piggybacks on WebRTC's data channels to send CRDT updates directly between peers.

The signaling server paradox

There's a chicken-and-egg problem: how do two browsers find each other on the internet if there's no server? The answer is a signaling server — a lightweight service that helps peers exchange connection metadata (IP addresses, network capabilities) during the initial handshake. Once the WebRTC connection is established, the signaling server steps out of the way. It never sees your actual data.

ComponentRoleSees your data?
Signaling ServerInitial peer discoveryNo
STUN ServerDiscovers your public IPNo
TURN ServerRelays data when direct connection failsEncrypted
WebRTC Data ChannelDirect browser-to-browser transferNo server involved

Offline persistence with IndexedDB

What happens when you close the tab? In a server-based app, your data is safe in the database. In P2P, the browser is the database. Yjs solves this by persisting the CRDT document to IndexedDB — a built-in browser storage engine. When you reopen the page, your data loads from IndexedDB instantly, and then syncs with any online peers to catch up on changes you missed.

Eventual consistency: the guarantee

CRDTs don't guarantee that every peer has the same state right now. They guarantee that once all messages are delivered, every peer will have the same state. This is called eventual consistency. In practice, with WebRTC, “eventually” means milliseconds — updates arrive almost instantly.

P2P collaboration is not about eliminating servers entirely. It's about eliminating the server as the owner of your data. The signaling server is a matchmaker, not a landlord.

Try it yourself

Put what you learned into practice with our Shared Todo List.