> a service should minimize the number of synchronous requests This doesn't feel like a goal for system design that should be persued without careful considera

> a service should minimize the number of synchronous requests This doesn't feel like a goal for system design that should be persued without careful consideration. Aside from the universal 'it depends', every technical decision has a trade-off, and the trade-off with making system-level events asynchronous is a system with more moving parts that need more monitoring, has more potential states, and seems harder to debug than one with necessary waiting just built in. > but by design they block progression until complete Isn't this often a good thing? If a result is required then chaining events that are independently failable but required to complete seems to create more work. > That being said, for an e-commerce application it may be actually feasible to make synchronous calls to the payment service by default, but fall back to asynchronous processing in case of failures. As the contract to sell typically only gets accepted when an item gets shipped, you still have the room to cancel an order if a payment falls through on the asynchronous processing path. Choosing to defer the requirement for payment acceptance is a very specific design choice that complicates the overall system by introducing new state(s). Maybe it's needed for your specific e-commerce application, but maybe just requiring payment at point-of-sale is simple and effective? > synchrony budget I'd argue that the budget should be for _asynchrony_, and operations should be kept synchronous until a genuine requirement for asynchronicity arises where the cost of adding that complexity justifies the result. Incidentally, it's interesting that broad system design concepts always seem to be based around strawman e-commerce applications.