Re immutability -- I would say a well written backend in any language would (probably?) throw away the entire state between each request being handled. It's pos

Re immutability -- I would say a well written backend in any language would (probably?) throw away the entire state between each request being handled. It's possible to introduce state, sure, but why and how does that happen? For very many backends the only natural thing to do is to code them stateless, keep all the state is in the database, and each new request starts in a fresh world. I see two common sources of state in any backend (monolithic or not): 1) Caching, whether resources or flags, whitelists 2) Connection pools. If there are ever any issues with those they can be segmented inside a monolith for a fraction of the cost of going to microservices (either using the same boundaries as if you had split into microservices -- or other boundaries, like just one set of caches/connection pools per endpoint handler..) So I agree with the OP that the social aspect and development process is the only rational for microservices. Otherwise, just scale the monolith horizontally to the same number of instances and you have strictly more ways to partition state; microservices only give you one way to partition state that may not even be the best one.