In this series of blogs, I will be sharing my knowledge, gained through reading and working, on one of the AMQP broker: rabbitMq.
We will start from basics like why do we need messaging protocol and what AMQP is, covering all basic building blocks of rabbitMq broker in later blogs, and will try to finish with some advance topics like rabbitMq cluster.
Let's get started.
Why do we need Messaging protocol?
A different paradigm of communication:
Why did we start using messaging ? Because we needed to communicate with each other.
Similar are the requirements of every software system... They need to communicate with each other (your order fulfillment service wants to communicate with notification service).
One way to communicate is through traditional HTTP requests:
However, they work synchronously... service1 (client) would make an API request to service2 (server), and would wait for response to ensure the message is delivered.
Now consider the case when service2 is down due to unavoidable situation. It will make direct impact on the performance of service1, and all messages will be lost.
Network errors too can cause such troubles.
Now consider a Messaging protocol:
Service1 and service2 are no longer client and server but publisher and subscriber respectively to a broker (e.g. rabbitmq).
Communication between them is no longer synchronous. Service1 publishes a message to broker and forgets it, having the trust in broker that message will be delivered to service2 at any cost.
Service2 went down ? Messages will be queued in broker and you have your time to finish counter strike match with peace, before fixing the service.
Loosely coupled System: You can have as many instances of publisher/subscriber as you want, without the interference from older ones.
For adding new instance of service2, http modal would have required us to manage new host, either at service1 or at loadbalancer.
I have only considered one use case of messaging protocol to give some insights of it. However there are many different ways in which messaging protocol stands out from other protocols like HTTP and so on.
Please note that I am not trying to convince you that AMQP(Or any Messaging protocol) is superior to HTTP. HTTP protocol has dominance in the market, and will be a good choice when a lot of 3rd party services need to interact with your service. So be wise (and make mistakes ;) ) before choosing which is more suitable for you.
Stay tuned for more RabbitMq.
Your comments are always welcomed...