Stateless vs Stateful Microservices

Question

I am reading some information about stateless microservices. And my question is simple. Is it true that if a microservice is having some persistence storage - that makes it stateful microservice. Is that always true? Any opinions will be well appreciated.

Answer 1

Statefullness and statelessness are not generally about DB persistence. Also, there are different levels of state(full)(less)ness, I will try to list some examples:

We could say a microservice is stateless if it does not hold information in its internal storage that is critical to serving clients, instead it holds data in external stores (which can be stateful). A good thought experiment is to imagine that your service restarts on a different node between each and every request. If the service can fulfil its purpose this way, it can be usually considered stateless. Another example is that load-balancers can randomly balance requests without using sticky sessions for stateless services. That's said if your service persists data in a local store (filesystem, etc...), then restarts in another node, and this data was critical for well-functioning, then it is not stateless. So statelessness is not strictly constrained to not holding data in memory.

Stateful service can be anything that holds a state between client accesses, and given this state is destroyed, some requests will fail.

Things get complicated with applications that are stateful internally but externally have a stateless API. For example, an actor-based system can be termed stateful (services know about each other), but automatic failover (actors from dead nodes are migrated to live nodes) can guarantee reliability if paired with persistent actor state storage. As you see, the overall service is stateful, but interactions are stateless through the API.

What is more important than these buzzwords, is how your application behaves in some edge conditions:

• Handling existing processes/sessions/requests during scaling (adding nodes)
• Handling the unexpected restart or termination of a service or node
• Handling requests during network partitions
• and more like these...

If your service can remain consistent and performant during these conditions, you are all good.