For messaging, we use SQL queues, not MQ queues. When a request comes into our front-end application, we put this message into a queue. The right service picks up a particular message from the queue, performs the operation, and calls the next service. The next service taking that message can either perform services on the message or attach it to a new queue from multiple services. It's as if we have multiple services working hand-in-hand, but we use a queue system to either get or send messages. I only use Amazon MQ for one specific thing. I wouldn't say I've used it extensively to know what is more beneficial. We use the solution to pick out matrices from a particular queue, process the queue, and process the messages they push into something else. It was really fast. One of the good things I love about the solution is that you hardly get two services working on one message. When a subscriber to a queue consumes their message, it's in the queue at a particular moment. All the messages are only visible to the particular subscriber. Suppose ten services are trying to get a message from the queue. Out of the ten, if five pick the same messages, you will get duplicate transactions and weird errors. It does a very good job abstracting that for you, so you don't have to write the logic. Amazon MQ has done all that it was supposed to do. Most of the issues boil down to a skill or a pricing issue. Overall, I rate Amazon MQ ten out of ten.
