Entering the world of a tech-based company from a background in journalism was challenging. Yes, I have been working with a computer daily for ten years, but I have never really given it a thought why stuff works or how, for that matter. My existence depends on it, though, and I can’t count all the times I’ve been frustrated when a web form crashed, and all my work just disappeared into nowhere. Sound familiar?
This, ladies and gentlemen, is why you need a message queue, among other times.
What is a message queue?
Think of a message queue as a mailman between a sender and a receiver, ensuring that the mail or data reaches its destination safely. If the mailbox somehow isn’t available, the mailman will hold on to the letter until it’s possible to deliver it to ensure that nothing ends up missing. This concept applies to basically anything that transfers data from one place to another.
Now, let’s return to my terrible web form case for a second; imagine there had been a message queue between me and the newspaper where I was trying to send my work. Then, all my work effort wouldn’t be lost if something went wrong after clicking “send.”
Suitable for who and what?
The free message queue RabbitMQ, which the CloudAMQP team specializes in, is very versatile and can be applied in a great variety of cases. In addition, it will safely transmit data and elegantly scale up and down when a heavy workload is expected; the mailman would get some help from his colleagues.
CloudAMQP’s 13,000-plus users have implemented RabbitMQ in very different ways. So whether it’s for gathering votes through a voting application or acting as a bridge between a garden bot in a physical garden to the software layer, rest assured that RabbitMQ will handle the tasks.
Do I need it?
Yes, you might do. But first, let me just walk you through some basic terminology.
In my previously mentioned case where the web application crashed, that was a monolith system, meaning that the parts of the system communicate directly with each other. Hence, if one piece of the puzzle goes down due to a heavy workload, like in the afternoon when most journalists were about to deliver their work, it can cause the whole application to crash.
Now, imagine we’ve implemented a message queue. Different functions in the application is divided into separate smaller specific applications called microservices. In this case, all the working parts act separated from each other. They are decoupled but with the magic mailman in between (RabbitMQ). This means you won’t lose any data no matter what happens on the way, either if it’s from or to the producer (sender) or the consumer (receiver). It will always be safely stored in the message queue until any upcoming problem is solved.
Understanding how a message queue works
Let’s imagine a test case where we order a pizza online. You go to the website, choose your favorite toppings, and then click “submit.” The webpage will ask for your payment method, where the pizza should be delivered, and which e-mail address to send an order confirmation. Several things are about to happen backstage in just a blink of an eye, starting with the producer placing several tasks into the message broker and dealing with them one by one in a first-in, first-out order:
- One message is being sent to the bank; to check the account balance and to make a withdrawal.
- The bank will respond with an “OK,” leading to the following two tasks in the message queue: first, to confirm and queue the order to the pizzeria, and second, to send an order confirmation message to the e-mail address.
- When the pizza is ready, a new message will be sent to the pizza delivery service, acknowledging that the food is ready to be delivered. This message also contains the address.
If, for example, there is a heavy workload at the pizzeria, two things can happen. Either the pizza guy can leave the order in the queue until he has time to bake your pizza, or he could call someone for help (=scaling up). All of the pieces in a microservice could be dependent on each other, but can also survive independently if something goes wrong in one of the connections.
Conclusions
A microservice is a suitable choice when like the pizzeria in our test case can expect peaks of many users simultaneously, such as Sunday night when people are too lazy to cook. This is where the microservice scales up to help deal with the customers waiting in line to pay for their pizzas.
On the other hand, if you know that your application only will be used by a few, or have a constant flow of users with no significant peaks, you might do as good with a monolith system. (=The little neighborhood kiosk doesn’t need five cashiers and an advanced ticket system to tell who’s next in line.)
I hope you found this blog post helpful and that message queuing doesn’t seem as complicated as before.
