[ekimekim]

First of all, because one of their explicit choices was to use HTTP. Using a persistent message bus like RabbitMQ has great advantages, but in terms of failure modes acts very differently to HTTP. For example, an upstream service failure would result in a timeout on getting a response (or ideally, a different instance of that service would respond to your message instead), rather than a more traditional TCP socket error or close.

Again, not necessarily worse, just different and unfamiliar.

The other reason is that this really only pushes the service discovery down a layer - how do you know where RabbitMQ is running? Of course, the same could be said for etcd - how do you know where etcd is running in order to query for more services.

[StavrosK]

Thanks for the explanation. I was looking for any dealbreakers with the MQ approach, but the concern you mentioned is valid. About pushing discovery down a layer, sure, but you'd do it the same way you'd query etcd, as you say.