What is your primary use case for CloudAMQP?

My main use case for CloudAMQP involves using it in various ways because it is a versatile technology, but the two main ones are as a publish-subscribe technology, using stream-type queues, and as FIFO queues for direct and asynchronous communication between two or more microservices. Between these two use cases, I consider both to be critical for my company's activities, because even if the publish-subscribe, the streaming one, can be considered a secondary use case, it has actually allowed us to cut costs and also reduce the number of microservices that were handwritten, so to speak, basically reinventing the wheel. Perhaps the second is more critical, the FIFO queues, because they made it possible to connect different data pipelines efficiently, particularly using the producer-consumer approach, even more complex ones, avoiding data loss thanks to resilience, and allowing us to scale very effectively even with thousands, almost millions of data points per second. A real situation where CloudAMQP made a difference in my architecture is in the producer-consumer and subsequent data lake pipeline of our main data ingestion engine. In particular, we did not use RabbitMQ, we used its variant LavinMQ, which is written in Rust, so the compiled language is much faster. In this case, we used the hash-type exchange, which in turn allowed us to distribute the load at the LavinMQ application level across many more data, making it even more scalable. Besides adding resilience, it also made it even more scalable because the producer and consumer were separated. The simpler producer receives the data but must be sure that they are saved and not lost. The consumer, which is obviously heavier, has to be sure that the data it receives is correct and that it is then subsequently handled by the engine that inserts the data into the data lake.

My main use case for CloudAMQP is developing proofs of concept to present to clients and, sometimes, to implement at clients through CloudAMQP's paid plans. For a client, I sometimes use CloudAMQP to develop a proof of concept that demonstrates to the client what it does, how it does it, and how advantageous it is compared to an on-premises version.

We used CloudAMQP to build the entire messaging layer of a SaaS platform whose goal is to be a platform similar to Power BI, in an agnostic sense, for analytics. At the same time, it's also the platform we use to generate some packaged offerings from it. Both of these ways of contracting our platform use CloudAMQP through the MQTT protocol to enable asynchronous communication for many of our processes or flows, including data ingestion flows and large-scale data ingestion, with the purpose of receiving what needs to be done in ingestion, as well as internal communication within the application—between nodes of a cluster, or between tenants of a cluster, or even something more cross-cutting that serves as messaging and notification between several clusters and the cluster responsible for processing that message and handling what needs to be done, or something that can be a broadcast, a fan-out, so that one of the nodes of a cluster, of one of the clusters in some environment, can process what we want to process according to the flow we may implement. The main use case for CloudAMQP is data ingestion, which became the core of analytics ingestion. Within data ingestion, there is a specific flow, which is the moment when we really need to do ingestion and reprocessing of data for all tenants of a cluster, for example, and this goes through a broadcast processing step where CloudAMQP ends up being our means both to control all these concurrent executions, based on a limit that we establish with the consumers that can keep listening to certain queues, and at the same time also becomes a major enabler for us in terms of resilience, in case our applications go down. This allows us to have a more resilient flow to deal with this and not lose messages that signal something that needs to be done or data that needs to be ingested.

My main use case for CloudAMQP is sending messages through exchanges and different queues, using different features. In this project, the idea was to send messages through exchanges and queues to create an infrastructure, a common core infrastructure, so the idea was to connect big ships and vessels to the headquarters. Since the ships go through the ocean for weeks or months, they might lose internet connection for days or even a week. CloudAMQP provides the perfect way of sending messages, and once the ship regains access to the internet, the messages will get back to the endpoint that they were supposed to reach. The option that messages can be requeued after a certain point is a critical part of our design of our infrastructure.

I primarily use CloudAMQP for asynchronous messaging and decoupling my microservices, which helps me handle background tasks, event-driven workflows, and balance workloads during traffic spikes without blocking user requests. During traffic peaks, my API offloads incoming events straight to a queue and responds instantly, with dedicated workers then consuming messages at a steady pace, preventing database overload and absorbing the spike without dropping requests. Another key benefit of CloudAMQP for me is error handling with dead-letter queues, as if a worker fails, messages are routed safely for retries without data loss or blocking the rest of the pipeline.

Our main use case for CloudAMQP is that we are using it for RabbitMQ operations as a message broker, with CloudAMQP managing RabbitMQ. Apart from that, we use it for microservice communication. In our use case, there are multiple consumers and applications. From the application side, a payload is uploaded, and multiple consumers communicate with this JSON, which is directly related to that particular application. We also use the RabbitMQ queue to process this data with the help of a synchronous technique. We have a multiple microservice-based architecture, and a quick specific example of how CloudAMQP fits into our workflow is that we have different operations involving order management and notification management, along with transactions related to payment. Our application sends the event, and different microservices consume that particular data. CloudAMQP is able to handle a huge amount of data and can manage these operations automatically, ensuring there is no spike and no lag inside the application.

CloudAMQP is mainly used for message queuing and asynchronous communication between applications and services. We have a hardware device which is made up of circuits, and it will communicate with the real-time dispenser unit in the fuel station. Once the data is taken from the fuel pump, it will transmit to the server. From the server, it will be queued in the AMQP and it will be displayed in the front end. CloudAMQP is deployed in our organization on our private cloud.

My main use case for CloudAMQP is using the clusters for queuing messages, and then the processor takes and processes them. A specific example of how I use CloudAMQP in my daily workflow is that I have a worker that I needed to scale based on the number of messages stored in CloudAMQP queues. I created an automation that runs every 10 minutes to check the queues, and if the number of messages exceeds a specific threshold, my workers scale up. Once the messages are executed, the worker scales down.