REST is not the source of the problem being described in the article. The problem in the article is from bad application of REST. I'm currently working at a st

REST is not the source of the problem being described in the article. The problem in the article is from bad application of REST. I'm currently working at a startup that has about 15 microservices and there are a few different strategies that we use to solve the problems being described in this article: We do use HTTP REST style requests when one service needs to fetch data from another service on the fly (usually in response to a user query), but we put in timeouts and proper error handling in case the dependent service is misbehaving. We strive for a "minimally broken" experience by allowing parts of the experience to degrade if one microservice is over capacity or broken, and have designed our response to allow us to return at least some data as long as part of the system is still working. This solves the "coupling", and "when microservices go pop" problem in the article. REST should be considered to be the interface for anything requiring realtime feedback, but not everything does require immediate processing, or immediate feedback. So for example there is no reason why the notification service should block anything as depicted in the authors example. The notification service could accept a POST request to dispatch the notification and immediately return a 200 response after placing the notification onto a queue. Then it can process the queue in the background in a non blocking manner. At some later point in time if a delivery receipt is absolutely required there can be a callback hook into the other service. REST makes for a very nice interface when used in an appropriate setting, but it isn't necessarily the best thing for all parts of the microservice communication. But neither is a service bus, or pipeline the best implementation for everything. The most masterfully designed backend will use REST when that is appropriate, and use a messaging/queue system when that is appropriate. Any non trivial backend will probably require both.