Prototyped P2P sync to reduce server hotspots.
The model: clients hold truth, servers coordinate.
Cheaper to scale, harder to design — worth it.

The more distributed systems I build, the more convinced I am that the protocol matters more than the platform. A fancy backend or container cluster can’t compensate for a brittle architecture. When users depend on always-available, low-latency data (like repair centres, insurers, or mobile capture apps), centralised systems become chokepoints.

That’s what drove my 2022 prototype: peer-to-peer synchronisation where the clients hold the truth and servers just help them find each other and keep time. It’s the exact opposite of the “all roads lead to the backend” mentality that’s dominated web design for a decade.

Why P2P?

It started from necessity: repair sites with patchy internet, technicians on mobile hotspots, ERP integrations that couldn’t wait for stable connectivity. Rather than pushing everything through one API gateway, I tested WebRTC + local databases for direct browser-to-browser syncing.

Think about it: if ten clients in a workshop already share part of the same dataset, why route every update through a cloud hub just to get back to the next bay? With P2P, each node holds an encrypted subset of shared state and syncs opportunistically. The result:

  • Less server load

  • Better local responsiveness

  • Built-in resilience if the central service goes offline

This philosophy aligns with what the distributed-web community calls local-first software: data owned by users, merged later via CRDTs or event logs. (inkandswitch.com)

The prototype architecture

The scaffold was small but mighty:

  1. Clients — PWAs with local IndexedDB + encryption; state managed via Yjs CRDTs.

  2. Signalling — lightweight WebSocket server to exchange peer offers.

  3. Transport — WebRTC DataChannels for direct data sync; STUN/TURN fallback if NAT blocked.

  4. Coordination server — stores metadata, conflict resolutions, and audit signatures (optionally via lightweight DLT, as in Post 19).

A simplified flow:

// On each client
const ydoc = new Y.Doc();
const provider = new WebrtcProvider(“repair-jobs”, ydoc, { signaling: [‘wss://signaller.example.com’] });

// Each peer edits shared data (jobs, statuses, photos)
ydoc.getMap(‘job’).set(‘status’, ‘In Progress’);

// Sync automatically happens via P2P DataChannels
provider.on(‘synced’, () => console.log(‘Peers in sync!’));


If a node drops offline, its local database still serves the UI. When it reconnects, CRDT merges handle any divergence. The central server becomes optional.

Real-world validation

This approach isn’t just theoretical. Several ecosystems already use similar thinking:

  • Figma’s multiplayer model uses CRDT-like diffing for near-real-time collaboration. (figma.com)

  • IPFS and Hypercore Protocol pioneered browser-level peer data exchange for resilience. (ipfs.tech)

  • Automerge and Yjs have become the go-to CRDT libraries for local-first apps. (yjs.dev)

These reinforce a trend: central coordination is useful, but ownership and state live at the edge.

Lessons learned

  • Cheaper scaling — because computation happens on clients, not servers.

  • Better offline support — local DBs make apps usable in dead zones.

  • Complex conflict logic — you must design merges and permissions carefully.

  • Security matters — end-to-end encryption and signed events are non-negotiable.

One unexpected benefit: debugging actually got easier. Each client was a self-contained testbed; I could inspect its local state and know exactly what it thought was true.

Real-world use cases

  • Repair workflows (Key2Key, Snap App) where jobs sync between bays.

  • Insurance scaffold apps where both insurer and repair centre update the same job record.

  • AI inference at the edge: multiple devices sharing local model caches before hitting the network.

A piece from The New Stack recently summarised this shift: “The next wave of resilient software won’t live in data centers — it’ll live in browsers, devices, and small local nodes.” (thenewstack.io)

Looking ahead

For 2026 and beyond:

  • Hybrid P2P + Kafka backbones for distributed event processing.

  • WebRTC mesh with SFU fallback for multi-party collaboration in low-bandwidth zones.

  • DLT-backed audit trails (lightweight signing of key sync events, see Post 19).

  • Decentralised identity — so peers can authenticate without a single IdP.

Final thought

Platforms come and go. Protocols endure.
When you design around the protocol — ownership, sync, privacy, resilience — you get systems that survive outages, clouds, and fads. It’s harder to design, but once it works, it’s beautifully boring — and that’s the kind of reliability I like shipping.