We were using the solution to setting the tenant settings into the service. For example, if you have five microservices using the tenant settings, after updated, we publish the updates to other microservices. It helps get the updated data to be able to publish the settings into the updated queue.

RabbitMQ allows for asynchronous solutions where previously everything was synchronous.

My company runs on high availability. It is known for high accuracy in its items that are being shipped.

To do this, drivers/vendors who are shipping these items have to send their location details frequently to the server to update their current location. It all depends on accuracy.

Based on this, the end user can plan to receive shipping items on his end. We wanted a JMS tool that can create 'queues' on the fly and pass messages from one system to another.

We're using this as our central messaging bus. It drives our micro-service architecture.

One of the key benefits for us has been the ability to use this solution for microservice architecture communications because it provides great flexibility. One of our clients was able to push messages from the source which were replicated and forwarded to all the other brokers nationwide. Everyone who needed it, received it, and it's very cost-effective. 

Our software has evolved dramatically over the past 18 months of development.

Major modifications to business logic have been handled easily. This is because each operation that the software performs has been atomic. That was then wired up with other operations via RabbitMQ exchanges/queues,

It allows for asynchronous development and horizontal scalability.

This allowed us to create a resilient network and independently scale various parts of the system dynamically as the business needs changed.

Legacy queuing systems have been replaced by RabbitMQ. The performance has been increased to a great extent.

We have been able to set up a messaging system that facilitates data integration between the software modules that we sell.

RabbitMQ allowed us to do this quickly so that we could focus on the business requirements, rather than divert our efforts to message broker implementations.

Once the architecture was proven, we were able to return to the RabbitMQ message layer in order to implement an HA cluster with a minimum of problems encountered.

Our business now has a fit-for-purpose information hub that we can apply across our systems. As the customer-base grows, we know that the hub can grow with it.

It allows developers to focus on application functionality without having to re-invent interprocess communication, which is difficult.

I also allows us to develop smaller, more efficient, and less complex subcomponents of a larger application.

We are using it to distribute pieces of some large jobs to multiple machines, which improves performance several times.

RabbitMQ helped us build a database synchronization framework that allowed us to transfer our clients data to our cloud based data processing centers.

With RabbitMQ cluster servicing micro-services, we don't have any downtime and we don't lose any data. We can update and/or upgrade the micro-services without downtime.

It made our system more scalable, resilient and easy to maintain.

Applying message queues in general has helped my company, BuzzNumber, to scale easily with the load.

We use it as our main microservices connection queue.

I introduced RabbitMQ to my company to bring about more scalability and redirect asynchronous tasks outside of the frontal web servers.

• Scalability was provided by the possibility to add on workers behind RabbitMQ. Asynchronous is the keyword for the message broker.
• I started to split our monolith website and remove all the heavy processes from our web servers.
• Dispatching the workload correctly helped to increase the response time.
• The frontal web server must focus on replying and not on doing reports/PDFs. You must have a dedicated server for this.
• The solution is written in Erlang. Erlang was built for telecommunication systems. One of its assets is that it can upgrade a service in production without downtime. That’s a good point!

I have used this solution for changing stock of products in an e-commerce project. We update the stock of products from RabbitMQ. Some of our clients can change the stock of a product, i.e., either increase or decrease it. They send the stock count to RabbitMQ as a message and our e-commerce platform changes the stock when it gets the message. Consequently, we update the database, cache, search engine service and so on.

There are too many advantages of using this solution. You can scale your processes and update your data in a nearly synchronous way.

This tool made our research process easier and allowed our administration (monitoring) process to happen at the same time. We created different queues for different use cases of the same streaming data.

RabbitMQ will help to remove a lot of the complexities and create a loosely coupled codebase.

• Quick and simple to implement

• Easy to build proof-of-concept modules based on working examples from Pivotal.

It provides us with a much better scale. We have never lost a single message with RabbitMQ.

The shared RabbitMQ Cluster has improved stability and maintainability of each application. We only have one message bus now.

We are now able to leverage real time applications and event driven architecture.

We had a project where we had huge responses to APIs from the front-end and had to handle such large responses/requests without losing any of them. RabbitMQ efficiently handled this problem by providing message queuing and decoupling our front end and back end.