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.