Why WebSockets and Serverless Don’t Fit Naturally
Cortlet is a software brand specailizing in: Lightweight, secure-first, no-bloat, problem-solving, and balance of opensource and closed source software.
WebSockets Are Stateful. Serverless Isn’t.
Serverless platforms are built around a simple model:
A request comes in, a function runs, a response goes out, and the compute can disappear.
That works extremely well for ordinary HTTP APIs.
WebSockets behave differently.
A WebSocket connection can stay open for minutes or hours. The client expects that connection to remain available so data can move in either direction whenever needed.
That creates a fundamental mismatch:
WebSockets are stateful. Serverless functions are not.
HTTP fits serverless naturally
A normal API request looks something like this:
Client → HTTP Request → Serverless Function → Response
The function does not need to remember the client after the request ends.
The next request may run on a completely different instance.
That is fine because each request is independent.
WebSockets expect something to stay alive
A WebSocket looks more like this:
Client ↔ Persistent Connection ↔ Server
Something has to keep that connection open.
It also has to know things like:
which client owns the connection
whether the connection is still alive
where to send data later
what happens when the client disconnects
how to reconnect after a network interruption
The connection itself becomes state.
A traditional long-running server can keep that state in memory.
A serverless function usually cannot.
So where does the connection live?
WebSockets are not impossible in a serverless architecture.
Instead, another layer usually has to maintain the connection.
A common architecture looks like:
Client → WebSocket Gateway → Serverless Function
The gateway keeps the socket alive.
When the client sends a message, the gateway triggers the serverless backend.
The function handles the event and exits normally.
The stateful connection layer and the stateless compute layer are separated.
That solves the basic architectural problem.
But it can introduce a new one.
The infrastructure starts growing
Once the WebSocket connection exists outside the backend, developers may also need to think about:
connection IDs
routing responses back to the correct client
connect and disconnect events
authentication
stale connections
reconnect behavior
connection tracking
provider-specific APIs
A feature that started as:
“We just need realtime updates.”
can quickly become:
“We now have an entire infrastructure layer just to keep connections alive.”
That is where the simplicity of serverless can start to disappear.
What if the backend stayed HTTP-only?
One possible architecture is to keep the persistent connection completely outside the application backend.
For example:
Client → WebSocket Gateway → HTTP Webhook → Serverless Backend
The gateway handles the long-lived connection.
The backend receives ordinary HTTP requests.
A WebSocket event becomes a webhook.
The backend can process it like any other request and remain stateless.
This is the architecture we are exploring with Cortlet.
The idea is simple:
Let one layer deal with persistent connections, while the application backend continues doing what serverless does best: handling short-lived requests.
Separation is the key
The issue is not that WebSockets and serverless cannot work together.
The issue is that they make very different assumptions.
Serverless assumes compute can appear, process something, and disappear.
WebSockets assume something stays around.
Once those responsibilities are separated, the architecture becomes much easier to reason about.
The interesting question is no longer:
Can WebSockets work with serverless?
They can.
The more useful question is:
How little WebSocket infrastructure should a developer have to manage themselves?