Partial failures. The Request service is promising atomic behavior to its callers, but it uses several primitives, which makes it difficult to honor that promise. For example, if a request, A, updates the address and "the usual," then it may succeed in updating only the address (due to a failure from the Config service, say, or a crash). That leaves the system in an inconsistent state I am not sure I understood this paragraph correctly, but isn't it a simple implementation detail of the "Request" service? If it fails to update, it should not proceed to placing an order -> "Sorry something went wrong with your order. Please try again." should be sent back to the customer. I do get the point, though, that with the monolith there are less points that you have to consider to maintain atomicity. Race conditions. Even in the successful case, inconsistency is possible. Well this one comes from (in my opinion) a poor design decision for how the services communicate in the given example. In the case of the pizzeria here, I would change the design of the system so that the "Request" service packs all necessary data in a "Place Order" job that is sent tot he "Order" service. So the order placement would contain { pizza : <Pizza ID in the products service>, delivery_address: "42 Universe street, Alabama" } This is good article nevertheless and the main message that microservice architecture brings extra complexity that is non-existent in monolith is very much true.

Some important points to consider when comparing DB support: Since v4, Strapi does not have a good support for DB transactions. The only option (which was added very recently) is to use low-level knex-based transactions which require intimate knowledge of the db schema to write properly, which is an issue because, as you put it in your article, they follow "closed" approach that is, developers don't get to choose how their schema going to look like. So, if ACID is something you need, Strapi may not be your cup of tea.

Simen Daehlin Yeah, all correct with regards to heroku, that's why there is no big advantage of docker over good old git-based. And, ideally Docker would give you that freedom you are talking about, yes. But with Strapi it is not so rosy. Strapi violates the principles of 12-factor app (the third one, to be precise) and embeds some of the environment variables in code at the build stage. At least one I am aware of (learned it the hard way) https://forum.strapi.io/t/deployed-strapi-admin-panel-trying-to-hit-localhost-1337/7598/7 Essentially that environment variable discussed in that thread gets burned into your Strapi build which makes the docker images not very reusable like you would expect. So, some suggested if you have multiple environments for a few customers, you are multiplying docker images. Combine it with the large image size and you will start questioning if Strapi is ready for container-based workflows. I guess there is still value in docker here. Using Dockerfile and docker in general as the way of describing dependencies and installation process is somewhat universal and will work across various environments (AWS, GCP, whatever) compared to having a proc file that only Heroku would understand.

And what is the size of the docker image that it produces? What is the benefit of running it in the docker image on Heroku vs traditional git-based deployment?