7

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.

saferJo
  • 497
  • 1
  • 5
  • 16
  • 2
    It seems you don't had understood what are the `state`. – Zorglube Nov 04 '19 at 15:44
  • 1
    `State` is the situation of the `User` using the service, stateless and statefull is aboute - if you need the state of the user to send him an response - where is memorised the state of the user. – Zorglube Nov 04 '19 at 15:47
  • ok so if in the database I have something like: user1-processing, user2-final; and in the code of the microservice I am checking if processing do1(), if final do2() - is that making the microservice stateful? – saferJo Nov 04 '19 at 15:51
  • 3
    NO. The state of the user is the session (id, groups, rights, previous actions, etc). – Zorglube Nov 04 '19 at 16:02
  • Normally REST stateless application perform a read on the DB to load necessary data for satisfying the request, process it and reply to user query. The terms stateless refers also and mainly to the lack of a server entity keeping data available from one request to the other without reading/writing the DB. – Sergio Arrighi Nov 04 '19 at 16:32

2 Answers2

17

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.

David Szalai
  • 2,363
  • 28
  • 47
4

"Is it true that if a microservice [has] some persisten[t] storage, that makes it [a] stateful microservice[?]

No, it is not true. If that was true, then virtually all microservices would be stateful, since virtually all microservices do utilize some form of persistent storage.

If you stop for a moment and take a somewhat distanced and agnostic look at a web application, any web application, from the point of view of a user, you will notice that it is most definitely not stateless. (If it was, then it would be pretty useless.) At the very least, it offers you some means of signing up and signing in, so it remembers you, and that's persistent state, which is kept in persistent storage. However, this web application is probably built out of stateless microservices. These microservices have access to the persistent state of the application, but that does not make them stateful.

A microservice is called stateful if it maintains some state of its own, and utilizes that state across service requests.

Whether this state is persisted or not is irrelevant. (Though it better be, otherwise the microservice is in danger of not being scalable and resilient, which would render it unworthy of being called a "microservice", but that's a different story.)

So, a stateful microservice would be one that would query the main persistent store of the application for information about you when you sign in, and then remember that information for as long as you remain signed in, so as to keep servicing requests from you without having to query the main persistent store of the application for this information on each request.

From the point of view of usability, the main difference between stateful and stateless microservices is this:

  • With stateless microservices, any instance of the microservice can handle any request from any client. There is no notion of "session", so any request coming into the farm can be routed to any server, and to any instance of that microservice within that server.

  • With stateful microservices, you have to have a session between a client and a particular instance of a microservice running on a particular server. All service requests that come into the farm and belong to that session must be routed to that particular server and to that particular instance of the microservice within that server.

Mike Nakis
  • 56,297
  • 11
  • 110
  • 142