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


Write your response…

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...

AMQP is a great messaging protocol. Messaging is an important part of what the web is about. HTTP is more widely used however. And there are few more messaging protocols each with their own benefits.

I can imagine exposing the system through AMQP partely provided using a HTTP/rEST, HTTP/jsonrpc2, HTTP/soap gateway. I can also imagine HTTP being used for some parts of the system (think microservices architecture where subsystems are partly exposed using HTTP) while all those subsystems are interconnected using AMQP, and to which you maybe also offer access. Depending on the messaging needs.

Yes! AMQP is great for interconnecting internal components and it's damn fast! For external APIs (JSON / SOAP), i simply add an HTTP endpoint on the frontend that's connected to the rest of the system via AMQP. This kind of setup is very easy to scale!

Write a reply...

Join a friendly and inclusive Q&A network for coders

  • 🖥Pick the technologies you like & read great content through your feed.
  • 💬Ask a question when you want to learn more about anything.
  • 🚀Share what you know & build your portfolio.
Sign up nowLearn more

loading ...