Microservices: REST vs Messaging

Question

I heard Amazon uses HTTP for its microservice based architecture. An alternative is to use a messaging system like RabbitMQ or Solace systems. I personally have experience with Solace based microservice architecture, but never with REST.
Any idea what do various big league implementations like Amazon, Netflix, UK Gov etc use?
Other aspect is, in microservices, following things are required (besides others):
* Pattern matching
* Async messaging.. receiving system may be down
* Publish subscribe
* Cache load event.. i.e. on start up, a service may need to load all data from a couple of other services, and should be notified when data is completely loaded, so that it can 'know' that it is now ready to service requests
These aspects are naturally done with messaging rather than REST. Why should anyone use REST (except for public API). Thanks.

Solution

A standard that I've followed in the past is to use web services when the key requirement is speed (and data loss isn't critical) and messaging when the key requirement is reliability. Like you've said, if the receiving system is down, a message will sit on a queue until the system comes back up to process it. If it's a REST endpoint and it's down, requests will simply fail.

Comments

[k1133]

HTTP,REST are specifications . RabbitMQ/Solace are message brokers. Is your question that "what are the applications of services based on HTTP/REST" ?

[Apurva Singh]

hmm maybe use cases where REST should be used and where messaging should be used, or a combination.. why this and not that kind of

[Sean Farmar]

+1, You may want to think about the coupling implications of synchronous communications (REST), if one fails all its dependents will fail, so in addition to losing the data it can cause a chain reaction that could bring the whole system down.

[MattDavey]

@SeanFarmar this is what I call the Domino Effect. A related issue is the Ripple Effect, where changes in one service can necessitate changes in downstream services.

[Bill Rosmus]

Sometimes you may want this behaviour. For example if you expect a fast synchronous response and you get a time out or some other server error, you can deal with it accordingly. Some processes are not tolerant of waiting. I'm sure there are other similar use cases to this.

[Vladimir Kovalchuk]

so why many minuses? Actually, REST based on HTTP methods! And yes, REST is sync!

[Sebastian Nielsen]

This is plain up wrong: HTTP is a contract, a communication protocol. REST is a concept, an architectural style which MAY use HTTP, FTP or other communication protocols. HTTP is one of the most commonly used communication protocols by REST, which is where you misconception stems from I guess.

[Angsuman Chakraborty]

REST is not faster than MQTT, a popular messaging protocol. "As per the analysis and test reports, MQTT data transfer can transfer data at a rate 20 to 25 times faster than REST Calls. ... MQTT Broker can process up to 40,000 messages per second on a commodity server." -- bevywise.com/blog/mqtt-vs-rest-iot-implementation

[elsamuray7]

Generally, messaging applications are easier to integrate because you can decouple application logic from your messaging endpoint, which makes applications easier to maintain and more reusable. However, developing a messaging endpoint can be blood and tears. If you only want to build a single purpose application you are better off with REST.