Amazon SQS

Simple and quick implementation makes it a first go to service when not familiar with queue management. Handling of Dead messages in queue is helpful, as over time these messages stack up causing lots of unnecessary processing at listener end. Retry mechanism for failed messages in systrem is a fine functionality as failed messages need to be handled for a fail safe system Delay implemeted to send message for polling makes it better to build a system which processes heavy data at listener end so to manage messages better before polling

I wanted to select "RabbitMQ" instead of IBM Cloud Messages for RabbitMQ....
At first, we have some instances running RabbitMQ but SQS is a fully managed queuing service it was way more convenient to use it and get rid of RabbitMQ !

To be blunt: Amazon SQS was the simplest to implement given our requirements. Other services in this space work just as well, and SQS does not have any benefits outside of being the easiest to implement when using an otherwise fully AWS stack. AWS itself even has other solutions that would work just as well, however, SQS had the most reasonable pricing model for our given situation. That will certainly not always be the case, but in several of the instances where we are using it, it just made the most sense.

The reason for the choice is due to maintenance needs and HIPPA compliance, as well as the great options under the AWS ecosystem, with very useful configurable parameters.

The most comparable products are RabbitMQ, and perhaps ActiveMQ. Until recently, AWS did not offer a managed ActiveMQ product. Running RabbitMQ will never be to my team's competitive advantage; we wanted a managed service.

Amazon SQS stacks up with the best of them as most of their products do. The only issue comparatively that I’ve had with this service, in particular, is the silently failing messages and then allocation of time to dedicate to debugging when the issue of why a message got stuck in a queue was unclear.