Stateful vs. Stateless Microservices: What's the Difference?

Microservices are the backbone of modern applications. They help businesses increase the speed of software development, seamlessly adopt new technologies as needed, and meet security and compliance mandates.

While there is little contention about the usefulness of microservices, there still exists quite a bit of confusion when comparing stateful vs. stateless. To help you make an informed decision about the best microservices for your business’s needs, we’re going to cover:

• The defining characteristics of stateful and stateless microservices
• Stateless microservice benefits and drawbacks
• Stateful microservice benefits and drawbacks
• How to choose between stateless and stateful microservices

Defining stateful and stateless microservices

As the name suggests, stateless microservices do not maintain any state across calls. They process requests without retaining any state information. This means stateless microservices are “forgetful.” In other words, no “memories” of previous transactions are stored after a completed transaction.

On the other hand, a stateful microservice carries its own state in some form to function. Actions are performed within the context of previous transactions, and these “memories” can be used to inform future transactions.

Stateless microservices: Benefits and drawbacks

In the cloud era, developers often turn to stateless microservices when building applications because they are easy to manage and massively scalable. Some of the other benefits of stateless microservices include:

• There is minimal memory overhead required, resulting in high elasticity.
• Abstraction means developers don’t need to worry about the underlying infrastructure.
• They are ideal for building applications with unpredictable user loads.
• New instances of an application can be added or removed as needed.

While stateless has become the go-to for today’s web and cloud applications due to ease of use and scalability, consider the drawbacks before committing to this architecture across the board.

For real-time use cases, stateless architectures face non-trivial problems. First, because state must be retrieved externally, an extra network trip is required to fetch the data. If this data resides on disk, which will typically be the case, the corresponding disk read will be about 80 times slower than reading from memory. Second, the decision of what to store has to take into account additional factors, such as the general usefulness of each type of data component, the feasibility with respect to the data rate when persisting to disk, the volume of data to be stored, and the cost of storing the data long-term.

Typically, storing all data is neither cost-effective nor feasible in real-time use cases. Some of this data will only be useful in a low percentage of the cases. If such data is stored, it adds latency and expense that is mostly wasteful. If it isn’t stored, it will limit the range of insights that can be provided, making it impossible to deliver certain categories of insights. Though a human will not be able to make a decision in very small units of time, for a system that can not feasibly store everything, the only time to act on all available data occurs in a small window of time before the data is discarded as new data arrives.

Other challenges of stateless microservices include:

• Lack of state means continuous database polling is required to determine if a value has changed.
• It is both time-intensive and costly to use a database to store any state needed for computation across events; while a serverless function is waiting on a database to respond, code is “running” and thus billable by the cloud service provider.
• There is lock-in when stateless microservices are tied to a particular serverless offering (e.g., AWS Lambda, Google Cloud Functions, etc.), limiting application portability.
• They are incapable of providing truly real-time insights at the lowest latencies for live automated operations.

Stateful microservices: Benefits and drawbacks

Stateful microservices supply the antidote for big data applications that cannot unlock real-time insights at sufficiently low latencies. The inability to access real-time insights often occurs because too much time is lost in a stateless model querying the database. As new applications in edge computing, AR/VR, IoT, the metaverse, and more emerge, the need for live data performance capabilities are greater than ever.

A few additional benefits to consider around stateful microservices include:

• They are ideal for edge data use cases where state changes occur rapidly.
• Promote an events-first method of processing and persisting state changes, which is useful for both real-time insights and downstream data analytics.
• Can be orchestrated into a stateful data fabric capable of analyzing, learning from, and predicting streaming data in real time.
• Specialized stateful microservices can perform real-time transformations as data flows or be combined with other microservices to create real-time aggregations.

With these strengths in mind, it’s worth acknowledging that there are certain challenges of stateful microservices (many of which have been solved by actor-based toolkits and platforms).

These include:

• The need for more compute resources means the architecture can be harder to operate without the proper systems in place.
• Managing resource isolation requires dependable memory and storage. Some may find it difficult to choose the right persistent storage types.
• It can be challenging to get developers to make the mindset shift to adopt stateful programming.

Fortunately, web agents (a type of actor) solve many of these hurdles by unifying state, compute, persistence, and messaging into a single, vertically integrated data processing architecture. For example, Verizon deploys Swim’s web agents on high-value entities to monitor and remediate issues before they can have a more far-reaching impact. [sum up how this ties to stateful]

Should my business opt for stateful or stateless microservices?

Choosing stateful vs. stateless microservices largely depends on the specific circumstances and desired outcomes for your business application(s). Fortunately, this doesn’t have to be an either/or decision — you can leverage the benefits of both stateful and stateless microservices across your organization and its various products and services.

However, when you must choose one or the other for a specific use case, don’t overlook the fact that stateful microservices are quickly becoming the superior option for a number of real-world scenarios. With the rapidly increasing demand for high-performance, stream-based systems, stateful microservices provide the best approach for real-time data access, visualization, and analysis.

A smarter way to use stateful microservices

Is your business interested in interpreting and acting on massive amounts of data in motion? Swim provides the easiest way to build real-time applications directly on top of streaming data. This way, you can unlock contextual insights at the speed of change.

If you’d like to try out our free, open-source platform for yourself, check out our project on GitHub and then hit the ground running with our project-based tutorials and guides.