Serverless WebSockets: Scaling Collaboration with Durable Objects

For years, the phrase 'Serverless WebSockets' was treated as an oxymoron. Serverless functions—like AWS Lambda or Google Cloud Functions—are inherently ephemeral, stateless, and short-lived. WebSockets, by definition, are the opposite: long-lived, stateful, and persistent.

To bridge this gap, architectural patterns traditionally relied on an external state coordinator, usually a managed Redis instance. While this works, it introduces the 'Redis Tax': additional latency, connection pooling complexity, and a significant increase in operational overhead.

Cloudflare Durable Objects (DO) fundamentally change this equation. By providing a globally unique instance of a class with its own persistent storage and the ability to handle WebSocket connections directly, they allow us to build state-synchronized applications without a separate database or pub/sub layer.

The Serverless WebSocket Paradox

In a traditional server-based environment, handling WebSockets is straightforward. A client connects to a server, the server keeps the socket open in memory, and you might use a local variable to track state. When you need to scale horizontally, you introduce a Pub/Sub layer (like Redis) so that Server A can tell Server B to send a message to its connected clients.

In a serverless environment, this becomes problematic for three reasons:

1. Execution Limits: Functions time out. You cannot keep a Lambda function 'open' for a 20-minute WebSocket session without paying a fortune or hitting platform limits.
2. Statelessness: Every invocation is a blank slate. There is no shared memory between 'Function A' and 'Function B'.
3. Discovery: How does a client find the specific function instance that holds the 'state' for a specific collaborative document or chat room?

Cloudflare Workers solved the execution limit problem with the webSocket API, but the 'Durable Object' is what solved the state and discovery problem.

Understanding Durable Objects as a State Engine

A Durable Object is a specialized Cloudflare Worker that is guaranteed to be globally unique. If you have a Durable Object class called ChatRoom and you instantiate it with the ID room-123, Cloudflare ensures that every request for room-123 from anywhere in the world is routed to the exact same physical instance.

This uniqueness is the 'holy grail' for collaborative apps. It means the Durable Object can act as the single point of truth. You don't need Redis to synchronize state because the state lives inside the Durable Object's memory and its attached persistent storage.

The Single-Threaded Advantage

Each Durable Object runs in a single-threaded event loop. While 'single-threaded' often sounds like a bottleneck, in the context of distributed state, it is a massive feature. It eliminates race conditions. When two users send an update to the same document simultaneously, the Durable Object processes them sequentially. You don't need complex distributed locking mechanisms; you just update the object's local state.

Building a Real-Time Collaborative Engine

Let’s look at a practical implementation. Imagine we are building a collaborative whiteboarding tool. Multiple users need to see each other's cursor positions and drawing paths in real-time.

1. Defining the Durable Object

In our ChatRoom class, we manage the list of active WebSocket connections and the current state of the board.

export class WhiteboardRoom {
  state: DurableObjectState;
  sessions: WebSocket[] = [];
  boardData: any = {};

  constructor(state: DurableObjectState) {
    this.state = state;
    // Retrieve persisted state if the DO was restarted
    this.state.blockConcurrencyWhile(async () => {
      this.boardData = await this.state.storage.get("board") || {};
    });
  }

  async fetch(request: Request) {
    const [client, server] = new WebSocketPair();

    await this.handleSession(server);

    return new Response(null, { status: 101, webSocket: client });
  }

  async handleSession(ws: WebSocket) {
    ws.accept();
    this.sessions.push(ws);

    ws.addEventListener("message", async (msg) => {
      const data = JSON.parse(msg.data);
      
      // Update local state
      this.boardData = { ...this.boardData, ...data };
      
      // Persist periodically or on change
      await this.state.storage.put("board", this.boardData);

      // Broadcast to all other participants
      this.broadcast(JSON.stringify(data), ws);
    });

    ws.addEventListener("close", () => {
      this.sessions = this.sessions.filter(s => s !== ws);
    });
  }

  broadcast(message: string, sender: WebSocket) {
    this.sessions.forEach(client => {
      if (client !== sender) {
        client.send(message);
      }
    });
  }
}

2. The Worker Entry Point

The standard Worker acts as the router. It identifies the 'Room ID' from the URL and passes the request to the correct Durable Object.

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const roomName = url.searchParams.get("room") || "default";
    
    // Get the ID for the named object
    const id = env.WHITEBOARD_ROOM.idFromName(roomName);
    
    // Get the stub (a reference to the DO)
    const roomObject = env.WHITEBOARD_ROOM.get(id);

    // Forward the request to the DO
    return roomObject.fetch(request);
  }
};

Optimizing with the WebSocket Hibernation API

The example above keeps the Durable Object 'active' in memory as long as a WebSocket is connected. While powerful, this can become expensive if you have thousands of idle connections.

Cloudflare introduced the WebSocket Hibernation API to solve this. It allows a Durable Object to serialize its state and 'go to sleep' while the WebSocket remains open. When a message arrives from the client, Cloudflare wakes the DO up, injects the message, and lets the DO handle it.

This transition from 'Active' to 'Hibernated' reduces costs significantly because you are only charged for the duration the DO is actually processing messages, not for the idle time of the socket connection.

Implementing Hibernation

To use Hibernation, you replace ws.addEventListener with the webSocketMessage method in your class. This tells the runtime that the class is capable of being hibernated.

export class OptimizedRoom {
  async fetch(request: Request) {
    const [client, server] = new WebSocketPair();
    
    // Set up the server-side socket for hibernation
    this.state.acceptWebSocket(server, ["room-tag"]);

    return new Response(null, { status: 101, webSocket: client });
  }

  async webSocketMessage(ws: WebSocket, message: string) {
    // This code only runs when a message actually arrives
    const data = JSON.parse(message);
    
    // Broadcast to everyone tagged with "room-tag"
    this.state.getWebSockets("room-tag").forEach(s => {
      if (s !== ws) s.send(message);
    });
  }
}

Why This Beats the Redis Stack

1. Zero Cold Starts for State

In a Lambda/Redis setup, your function must first connect to Redis (latency), authenticate (latency), and fetch the state (latency) before it can even process the message. With Durable Objects, the state is already there, often in the same memory space or on a local NVMe drive in the same data center.

2. Simplified Consistency Models

Distributed systems are hard because of 'eventual consistency.' If two users update Redis at the same time, you have to handle conflicts. Since a Durable Object is a single instance, it provides strong consistency. The order in which the DO receives messages is the canonical order of events.

3. Reduced Infrastructure Surface Area

By using Durable Objects, you eliminate:

• The Redis Cluster (and its maintenance/scaling).
• The Load Balancer configuration for sticky sessions.
• The VPC/Networking complexity of connecting serverless functions to a database.

Strategic Considerations and Limits

While Durable Objects are revolutionary, they aren't a silver bullet. Senior engineers should be aware of the following trade-offs:

• Regionality: By default, a Durable Object is created in the data center closest to the first user who requests it. If you have a user in London and a user in Tokyo collaborating, one of them will face significant cross-continental latency. Cloudflare recently introduced 'Jurisdictional Restrictions' and 'Location Hints' to help manage this, but it requires manual planning.
• Storage Throughput: The state.storage API is backed by a distributed key-value store (based on FoundationDB). While fast, it isn't designed for high-frequency small writes (e.g., 60fps cursor movements). For high-frequency data, it's better to keep state in memory and flush to storage every few seconds.
• Vertical Scaling: A single Durable Object is limited by the CPU power of a single thread. If your 'Chat Room' grows to 50,000 active users, a single DO will struggle to process the broadcast logic. In these cases, you must implement a 'tree' or 'shard' architecture where multiple DOs handle subsets of users and communicate with a 'root' DO.

Conclusion: The New Standard for Real-Time Apps

Cloudflare Durable Objects represent a shift in how we think about the 'Edge.' It is no longer just a place to cache static assets or run simple redirects; it is a stateful compute layer.

For collaborative applications, the move to serverless WebSockets via Durable Objects offers a rare 'triple win':

1. Developer Experience: Write standard TypeScript classes without worrying about infrastructure.
2. Performance: Colocate state and logic at the edge, minimizing the 'Redis hop.'
3. Cost: Pay only for active compute time, especially when utilizing the Hibernation API.

If you are starting a new project that requires real-time synchronization—whether it's a multiplayer game, a collaborative editor, or a live auction platform—skipping the managed Redis and building on Durable Objects is the most architecturally sound decision you can make in the current ecosystem.