Serverless: Why Separating Protocol from Application Logic Changes Everything
The idea isn't new. But, you may not have heard it framed this way.
Founder at Proxylity
The argument for serverless usually starts with "no servers to manage" or "pay only for what you use." Those are real benefits, but they're consequences of something more fundamental: separating protocol handling from application logic.
When you run a traditional server, whether it's NGINX, Express, a game server, or a custom UDP listener, your protocol layer and your application logic share a process. They share memory. They share a lifecycle. And that coupling has consequences that load balancers and containers can't fix.
The Costs of Sharing a Process
On a traditional server, protocol state and application state are entangled:
- Protocol state: TCP connections, TLS/DTLS sessions, handshake context, connection IDs
- Application state: user sessions, in-flight requests, cached context, business workflow
They live in the same process, in the same memory. When something happens to that process (a deploy, a crash, a scale event) both layers feel it. Every user on that instance feels it. Connections time-out, reset and restart.
Load balancers help distribute traffic and help handle the recovery load, but they don't isolate concerns. A TLS upgrade from 1.2 to 1.3 still requires a process restart. An application code deploy still kills active connections. A crash still drops every session on that instance.
You can put a ton of effort into connection draining, load shedding and error handling but you never escape the fundamental problems coupling creates.
What Changes When You Separate Protocol from Logic
With a serverless pattern, for example using API Gateway + Lambda for HTTP, or Proxylity UDP Gateway + Lambda for CoAP, the protocol layer and application logic run in different places with different lifecycles:
- The gateway owns the protocol: connection management, TLS/DTLS termination, handshakes, keep-alives
- Lambda owns the logic: your code, your business rules, your per-request processing
Neither knows nor cares about the other's internals. And that changes the impact of every operational event your team faces.
The Comparison
Here's what happens when six common operational events occur, depending on whether protocol and application logic share a process or not:
Event | Traditional Server (Coupled) | Serverless Gateway (Decoupled) |
|---|---|---|
Protocol upgrade (e.g. add TLS 1.3 support) | Process restart required. All active connections and sessions are dropped. | Gateway upgrades independently. Lambda functions are untouched. Zero application disruption. |
Application code deploy | Deploy restarts the process. Protocol state and application state are both lost. Users are disconnected. | New Lambda version deploys. Gateway continues handling connections. No interruption. |
Scale-out event | New instances cold-start without session context. Session affinity breaks. Users may need to re-authenticate or reconnect. | Lambda scales instantly per invocation. No sessions to migrate, no affinity to break. |
Process crash | Every connection on that instance is killed. Every user session is lost. Recovery depends on reconnection logic. | A single invocation fails. The next packet or request gets a fresh execution environment. Other users are unaffected. |
TLS/DTLS re-handshake | Handled in-process. Re-handshake load competes with application logic for CPU and memory. | Gateway handles it. Application never sees it. |
Session migration | Complex. Requires external session stores, sticky sessions, or forced reconnection. Often just doesn't work cleanly. | Nothing to migrate. Each invocation is stateless. State lives in DynamoDB, S3, or your external store by design. |
In the coupled model every operational event is a user-facing disruption. In the decoupled model, each layer absorbs its own changes independently.
This Isn't a New Idea
Separation of concerns is one of the oldest principles in software engineering. What's changed is that cloud services now make it practical at the protocol level, not just at the code level.
API Gateway has been doing this for HTTP/HTTPS for years. You don't manage TLS certificates in your Lambda function. You don't write connection pooling logic. You don't handle keep-alives. The gateway does that, and your function just processes a request object.
The same pattern now extends to UDP. With Proxylity UDP Gateway, the gateway handles UDP packet reception and optionally WireGuard termination, and your Lambda function receives a clean payload. Upgrade the encryption layer? The gateway handles it. Deploy new game logic or IoT processing? Lambda handles it. Neither disrupts the other.
The Effect: Development Velocity
When your protocol and application logic are decoupled your team moves faster. Reducing the risk and fear of disrupting customers has that effect.
- Smaller blast radius means more confidence. Developers deploy more frequently when they know a bad deploy won't kill active connections.
- Simpler testing. You test your business logic with a JSON event, not a full protocol stack.
- Pay-per-use economics. No idle servers waiting for traffic. No over-provisioning for peak load.
And this extends to AI-assisted development, too. When your business logic is a Lambda function that takes a JSON event and returns a JSON response, an AI coding agent can reason about it, test it, and iterate on it without needing to understand TCP state machines or TLS handshake flows. The cleaner the interface, the more effectively agents can help you build.
The Takeaway
The next time you're building a service on HTTP, WebSocket, CoAP, UDP, whatever the protocol -- ask yourself: does my application logic need to share a process with my protocol handling?
If the answer is no (and it almost always is), you've just eliminated an entire class of operational disruption. Your protocol layer upgrades independently. Your application deploys without downtime. Scaling is seamless. Crashes are isolated.
That's not just a serverless pitch. It's good architecture. It's good for your customers.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article