When designing Service Oriented Architectures, which one do you use - HTTP or AMQP?

This answer has received 1 appreciation.

If you're building for large intranets and have close communication with developing parties on both sides, I'm sure AMQP is a great protocol/standard to use. If you're building for the web/cloud, it seems to me you're better of with the standard that is already in use, adopted and useable without extra effort on standard hardware: HTTP/REST

I've personally built HTTP APIs and eventually rewrote them using AMQP since HTTP couldn't give me guaranteed message delivery (some messages would drop and you wouldn't know about it), couldn't give me overload protection unless I add some specialist layers on top of HTTP (whereas AMQP I could add timeouts on the queues, limit the message rate, move messages I can't immediately process to other queeus so I could notify the publisher that they weren't processed),

I had to build service discovery features with HTTP whereas with AMQP you don't care where the service is sitting, as long as it can see the queue system, with HTTP I had to write code if I want to reroute messages in any way, with AMQP I just add another queue to the exchange and I have plenty of options to reroute messages with many filter options.

With RabbitMQ you get federation and shovel plugins to shovel messages between different instances of RabbitMQ, so if your backend-services goes down for any reason, simply shovel the messages to another instance of RabbitMQ somewhere else so that another backend can process those messages.

Load balancing with RabbitMQ is a breeze, simply add a load balancer in front of different RabbitMQ instances, setup those instances in a cluster formation and startup more services to process messages, with HTTP you need to load balance each individual service.

With RabbitMQ, if I restart a backend while processing a message and it's not done yet, it will requeue automatically and the other backend service will pick it up and process it.

With Java and Spring, I can route all my logging of all applications via RabbitMQ, so I can have all the logging in one place or even write it to a NoSQL database if I wanted to.

With PostgreSQL I can add RabbitMQ on top of the DB as a DB-load-balancer, so writing will do a fan-out to all databases connected, whereas reading will only read from one DB at a time, so using RabbitMQ as read-load-balancer for PostgreSQL just works brilliantly. I can even use it to keep two databases in sync if they are running on different continents, RabbitMQ works well accross continents and adding TLS to RabbitMQ means all that DB-traffic is encrypted.

AMQP is awesome :-D

Write a reply...

Never miss an answer from Jos Fabre,
when you sign up for Hashnode. Learn more

loading ...