Stateless Architectures Win

Computing in distributed systems is difficult. However, we live in a distributed world: the Internet, web apps, and most mobile apps would not be able to run on only one huge central server. So if your solution isn’t a niche for a handful of users you’re better off with a stateless architecture.

Benefits

There are three major benefits:

• Scalability: Stateless systems can be scaled horizontally, and in theory there is no upper limit. The server doesn’t have to allocate and manage resources between requests.
• Reliability: If a node of a stateless system fails it can be easily replaced with another node that works. There are no total failures because a failure is limited to one node and not the whole system.
• Visibility: Since a stateless request is self-contained you don’t need additional information to analyze and understand its nature. It’s pretty much self explanatory and can be isolated.

HTTP and REST

The probably most successful and widespread application of a stateless architecture is the Hypertext Transfer Protocol (HTTP). The Internet wouldn’t be possible without HTTP. Representational State Transfer (REST) is an architectural style that formalizes some of the HTTP design decisions. Both HTTP and REST are tremendously successful.

Stateless Services

Remember EJB 2.1 Stateful Session Beans? I do. They were beasts. Accidental complexity at its best. So let’s forget about them and let’s concentrate on stateless services. That’s how I learned to build web applications 15 years ago and it proved to be the right approach in almost any case. The programming model is simple and easy to understand.

State — on the other hand — needs to be handled differently. It belongs to a backing service such as a database that is specialized to cope with it.

Serverless

Serverless applications are not bound to a specific server or group of servers. Instead, every request is executed on an ephemeral server which is shared with other serverless applications. So there is no chance of maintaining server-side session state. State has always to be persisted using third-party or backing services.

There’s always a trade-off when architecting an application. Adding state like session data doesn’t make it easier. Scalability is limited, fault tolerance is limited and you’ll potentially end up using some proprietary clustering mechanism. So my belief is that stateless architectures are the better approach in almost any case.