The Architectural Friction Between WebSockets and Serverless

Serverless architecture and real-time WebSockets are both popular choices for modern web development, but they operate on fundamentally opposing paradigms. Combining them directly often introduces unexpected operational complexity.

The Core Conflict: Stateful vs. Stateless

The core issue comes down to state management:

• Serverless is inherently stateless. It is designed around short-lived, event-driven execution: a request triggers a compute instance, processes the workload, returns a response, and immediately shuts down.
• WebSockets are inherently stateful. They rely on persistent, long-lived, bidirectional connections where the server continuously knows who is connected and where to push incoming events.

HTTP Model:      Client ─── Request ───► [ Short-Lived Function ] ─── Response ───► Client
WebSocket Model: Client ◄──────────────── Persistent Connection ────────────────► Server

How Teams Bridge the Gap (And Why Infrastructure Bloats)

To make persistent WebSockets work with ephemeral compute, developers usually introduce an intermediary managed service or proxy layer, such as a WebSocket Gateway:

$$\text{Client} \iff \text{WebSocket Gateway} \implies \text{Serverless Function}$$

In this model, the gateway maintains the long-lived socket connections with clients and invokes a serverless function only when an event occurs.

While this solves the initial architectural mismatch, it often introduces significant management overhead:

• Connection Tracking: Storing and retrieving unique connection IDs across distributed systems.
• Lifecycle Events: Handling explicit connect, disconnect, and unexpected reconnection states.
• Routing Overhead: Managing how asynchronous responses map back to specific open sockets.
• Stale Connections: Cleaning up ghost sessions caused by network drops.

What starts as a simple goal—"We just need real-time notifications"—frequently evolves into managing a complex web of connection-tracking infrastructure.

A Simpler Alternative: Keeping the Backend HTTP-Only

Instead of tight integration between the WebSocket layer and serverless functions, a cleaner approach decouples connection management entirely:

$$\text{Client} \iff \text{WebSocket Gateway} \xrightarrow{\text{HTTP Webhook}} \text{Serverless Backend}$$

Under this pattern:

1. The WebSocket Gateway owns the persistent client connections.
2. Incoming WebSocket events are converted into standard HTTP webhooks.
3. The serverless backend handles these webhooks as normal, short-lived HTTP requests—remaining 100% stateless.

Key Takeaway

WebSockets and serverless can work together, but force-fitting stateful logic into stateless functions creates unnecessary friction.

By separating responsibilities—letting a dedicated gateway handle persistent connections while serverless handles event processing—you keep your backend stateless, scalable, and easy to maintain. The goal isn't just making WebSockets work in serverless; it's minimizing the infrastructure burden required to support them.