- Many microservices are based on REST interfaces. However, the perceived simplicity of REST services can easily backfire when you take availability into account.
- Consider a system of N microservices that depend on each other via REST calls. This system only works if all microservices are up and running. In other words, this system does NOT work if at least one of these microservices is down or unavailable. The risk of this happening becomes much higher as N grows.
- There are patterns like the "circuit breaker" and other tricks to fall back to some reduced level of operation, but this greatly complicates the code and the development of these systems.
- Instead, what you can do is favor asynchronous communication via, say, messaging over queues. The light-weight brokers that just allow you to send a message to a remote consumer. If the remote consumer is down, no problem: the message will be queued until the consumer comes back up.
- If possible, try to implement messaging architectures with fire-and-forget event publication, so you don't even need to bother waiting for reply messages. It makes the coding even simpler.
- Instead of N services depending on each other, each service now depends on just the broker (But think about single point of failure, whcih is undesirable for high availablity systems) being there. More sophisticated designs are possible where brokers have local "proxies" at each service
- Availability of the overall system is much higher, since individual service failures are hidden from the clients.
- Services become simpler to code, since the typical circuit breaker logic is no longer needed, and you don't need timeout logic nor reconnect / retry code.
- Services become more scalable, because the queues allow you to apply the "competing consumer" pattern to get horizontal scalability without extra components like load balancers.
- There is one notable exception: you should consider synchronous interfacing like REST only if you need the result / response of a call to the remote service. In my experience, all other things can easily be modelled as queued messages.
Credit: Dr. Guy Pardon