Edge Realtime Sync

Making multiplayer apps feel instant, even across the world.

The idea

If two users are collaborating on a document, and they are both in Tokyo, but the central database is in New York, every keystroke takes 200ms to cross the ocean and 200ms to come back. The app feels laggy. Edge Realtime Sync fixes this by placing a tiny, lightweight "Edge Server" in Tokyo. Both users connect via WebSocket to the Tokyo Edge Server. When User A types, the Edge Server broadcasts the keystroke instantly (5ms) to User B, and then lazily syncs the change back to the New York database in the background.

Step 1: The standard approach. Every keystroke goes all the way to New York.

How it works (WebSockets at the Edge)

Services like Cloudflare Durable Objects or Supabase Realtime deploy WebSocket terminating servers to hundreds of cities globally. Your users connect to the closest one. These edge servers hold the "room state" in RAM, applying Operational Transformation (OT) or CRDTs to merge typing conflicts instantly, before sending the finalized document back to the central database.

// Connecting to the closest Edge node automatically
const socket = new WebSocket('wss://edge.example.com/doc/123');

// When User A types, it hits the Edge server and instantly broadcasts
socket.send(JSON.stringify({ type: 'insert', pos: 5, char: 'H' }));

// Edge Server (pseudocode):
function onMessage(doc_id, msg) {
  // 1. Instantly broadcast to all other users in Tokyo (5ms latency)
  broadcastToRoom(doc_id, msg);
  
  // 2. Add to a queue to save to New York DB later (Async)
  dbSyncQueue.push({ doc_id, msg });
}

Cost

Managing state at the edge is incredibly complex. If the Tokyo edge server crashes before it syncs with New York, data is permanently lost. Also, if a user in Tokyo is collaborating with a user in London, one of them still has to suffer cross-continental latency, because the "Room" can only physically exist on one Edge server at a time.

Watch out for