Using RabbitMQ in real life

The most common use case for RabbitMQ is a single producer, single consumer queue. Think of it as a pipe where one application puts messages into one end of the pipe and another application reads the messages that come out the other end. Messages are delivered in first in, first out order. These messages may be commands or contain important data. This sounds easy, but where could this type of architecture be applied? It's time to understand when and why message queuing shines!

Message queues between microservices

Message queues are often used in between microservices, but what does that mean?

Microservice architectural style divides the application into small services, with the finished application being the sum of its microservices. The services are not strictly connected to each other. Instead, they use, for example, message queues to keep in touch. One service asynchronously pushes messages to a queue and those messages are delivered to the correct destination when the consumer is ready.

The microservice architecture is often compared and contrasted with the monolith architecture, where the entire system is bundled together into one piece of software. One application is not only responsible for a particular task; it actually performs every step needed to complete a particular function. Monoliths communicate within the system since all the parts are running in the same process. This system is highly coupled since every function is reliant on the others.

In an example of a webshop built on a monolith architecture style, one system handles all of the functions, including inventory, payments, reviews, and ratings and so on, as shown in the following diagram:

A webshop built on the microservice architecture, on the other hand, means that each part of the system is an individual activity. One microservice handles reviews and ratings. Then, there's another inventory, and then yet another for payments, and so on, as shown in the following diagram:

Each pair of requests and responses communicates independently. This is known as stateless communication. While many microservices are involved, they are not directly dependent on each other.

Another typical use case for RabbitMQ is as a task queue, which we'll cover in the next section.

Event and tasks

Events are notifications that tell applications when something has happened. One application can subscribe to events from another application and respond by creating and handling tasks for themselves. A typical use case is when RabbitMQ acts as a task queue that handles slow operations.

Let's take a look at two examples of this:

• Imagine a social media application such as Instagram. Every time someone publishes a new post, the network (followers) needs to be informed about the new post. This could be a very time-consuming operation. Millions of people could be trying to perform the same task at the same time. The application can, with the use of message queues, enqueue a task onto the queue for each post as it arrives. When the worker receives the request, it retrieves a list of followers for the sender, and updates each of them.
• As another example, think of an email newsletter campaign tool that is sending out thousands of emails to thousands of users. With a possible scenario where many users trigger bulk messages at the same time. The email newsletter campaign tool needs to be able to handle this volume of messages. All these emails can be added to a push queue with instructions to the worker regarding what to send and to whom. Every single email is handled, one by one, until all the emails have been sent.

The following diagram shows a task queue, where messages are first entering the queue, and then handled. New tasks are then added to another queue:

With that, we've looked at and reviewed two typical use cases. The benefits of RabbitMQ have been apparent in each. We'll make this even more evident by exploring the benefits of message queuing in the next section.