Think of ActiveMQ before designing an application

ActiveMQ, an open-source Message Broker

If your applications need only things like asynchronous communication, eventual scaling of consumers and producers, retry logic and that too with something that is open-source, ActiveMQ is a must thought.

A Message Broker is a pattern which is designed for the purpose of consuming messages from applications. ActiveMQ or any message broker middleware (Queue Implementation) are designed for the purpose of sending and receiving messages between two/more applications, or components inside one application. Just think of Producer-Consumer problem during high school days to understand in details.

Why I used ActiveMQ and not the databases while designing an application?

Databases are basically for searching over multiple tables, but the requirement is reading messages, one at a time, in a FIFO like fashion. The application can also require one to push messages to consumers instead of consumers polling for a new one via a SQL query.

Apart from this, with RDBMS, one typically needs to update a flag indicating that the row has been processed to avoid repeated processing but with Message Queues, you only have to acknowledge a message and the next consumer will process the next one.

In brief, one should use a database for persistent data and not for temporary data. Assume that you have to send a message from Sender to Receiver. On Receiving the message, Receiver executes one operation (receive, process and forget). After processing that message, you don’t need that message at all. Here, the broker comes into the picture.

I used ActiveMQ in production while designing an application at our end, the reason being we had multiple requirements of concurrent Consumer-Producer Model and we also wanted the Retry Logic to handle the rare exception occurrence at third-party services; AWS, Google DBM, if any.

Implementation of ActiveMQ :

Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client.

JMS, an API which ActiveMQ implements, is an important foundation in Java Enterprise applications. This makes messages share a defined format and semantic, which makes the integration between multiple applications easier.

Additional Features of ActiveMQ :

Though ActiveMQ offers a lot of benefits against databases as highlighted above; I believe below are the points which I would like to emphasize in support of using ActiveMQ in any new application the developers wish to design.

1. Decoupled: The systems are able to communicate without being connected. Queue lies between systems, one system failure will never affect others as communication is done through Queue. The systems continue to work when they are up.

2. Recovery support: The messages in Queues itself persisted. The messages can be restored later if the Queue fails.

3. Reliable Communication: Consider an application that process client requests. In an average case, the system receives 200 requests per minute. This system is unreliable when a number of request goes beyond the threshold. In such a case, Queue can manage requests and it can push messages periodically based on system capacity without breaking it.

4. Asynchronous: Client-server communication is asynchronous. Once the client sends a request to the server it can also do other work without waiting for a response. When a response is received, the client can handle it anytime and acknowledge later.

5. Redelivery Policy: If a client fails processing message A, that message will get placed back on the queue according to a defined redelivery policy as we configure in the ActiveMQ setup. The default can be overridden to suit our needs by binding one to the overridden ConnectionFactory client side as we do in our work as and when required.

Below is our Spring Boot implementation of ActiveMQ, deployed and running in the production.

SpringBoot implementation of ActiveMQ

Feel free to reach out to me at : https://www.linkedin.com/in/ashutosh-kumar-9a109864/