This post discusses the stateless microservice design pattern; it is meant as
support material for other posts of mine that discuss microservices, mainly
michael.gr - The Stateful Microservice.
Is statelessness a requirement for a microservice?
In another post (see
michael.gr - So, what is a Microservice, anyway?) I discuss what a microservice really is, and I come to the conclusion that
despite various attempts out there to define microservices using
twenty-item-long lists of characteristics, a good working definition could be
as simple as this:
A microservice is a scalable and resilient module.
Even if you disagree with the terseness of this definition, and you regard
microservices as necessarily more than that, I hope you will at least agree
that it is precisely scalability and resilience that statelessness in microservices aims to address, so my definition serves its
purpose at least in the context of this series of posts.
There are many who will try to convince you that in order to build a scalable
and resilient system, you need statelessness; so much so, that microservices
have almost come to be regarded as synonymous with statelessness. This post
examines whether this is that in fact so, and what is the cost of doing things
this way.