Good points! In the partial failure case, the request that fails to update some information would indeed not place an order. The problem is that there are 2 requests: the first fails halfway after updating the address, and the second does not specify the address or the usual. If the node handling the first request crashes, the service would not be able to undo the update or even return a reasonable error message to the first caller. Your suggestion for a better contract is definitely an option and is mentioned in the article. However, in practice, it's easy to overlook these failure modes and only realize the complexity after they happen (especially if the system is used in unexpected ways).

Good question. The scope of each service is less about scale (because we can generally run as many instances as needed) but rather about the shape and complexity of the overall system and flow. For example, it's reasonable to implement three independent aspects as three separate services. Or to implement a two-phase system as two services. There is nothing wrong with small-scope services, per se, from a correctness point of view (although operational overhead is another matter). However, the microservice approach gets into trouble when it breaks up tightly-coupled functionality into multiple services -- and then the failure modes pile up. In my experience, team structure or existing unmergeable codebases sometimes make the problems with such a service division the lesser evil. But it's not ideal.