Amazon SQS Reviews

I am using Amazon SQS as part of my use of AWS over the past ten years. I have been leveraging it for data transitions between different systems, especially in my current project. It helps in creating different sporadic systems that can interact asynchronously.

Amazon SQS aids in facilitating the communication between systems by allowing asynchronous operations. This helps in managing systems that don't have to be in sync and can reduce costs through better management of data flow and infrastructure.

I am using multiple services such as AWS Lambda, S3, EC2, ECS, and the SNS SQS services, along with QuickSight reports and some of the VPC concepts. 

We have an email notification system integrated with Spring Branch. Once a batch job completes, SNS and SQS trigger events, sending notification emails to users. These notifications are based on user lists fetched from the database.

The most valuable features of the solution are AWS Lambda services, ECS, and QuickSight reports, which are beneficial for data analysis. SQS is also appreciated for messaging and querying needs.

In the past, we used Amazon SQS to synchronize distribution systems, particularly for logistics and managing customer orders. It served as a framework for asynchronous connection between different parts of our application, handling around ninety thousand messages per hour with multiple workers processing them. Currently, we use it to integrate with the logistic departments of the automotive industry, suppliers, and carmakers.

Amazon SQS provides an asynchronous glue that is essential for our system. It helps us scale efficiently and manage the workflow with either high parallelization or queued processing. The maturity and stability of the service contribute significantly to our integration projects.

The most common use case for Amazon SQS is decoupling an application. Instead of having one monolithic service with a timeout of about a minute, and if there are too many requests at the same time that might fail, the application can be decoupled by deconstructing the monolith into its own microservices. A JSON interface is designed, which has an agreed-upon schema, and in front of each microservice, a queue is installed where messages are sent. It's a common pattern, especially in the development of software solutions that run on an EKS cluster, to use Amazon SQS to enable asynchronous processes.

Amazon SQS has significantly helped by allowing applications to run asynchronously. It enables services to scale by ensuring requests do not overwhelm servers, which can be particularly useful for tasks like generating long videos using AI. By employing SQS, insights into queue lengths are available, and resources can be scaled appropriately without managing a task database.

The solution is used within our company's services, specifically within our microservices. One of the major reasons we use the tool is for retries and different flows. We work closely with e-commerce websites. Whenever we place an order, and if it fails for some reason, we use Amazon SQS to handle the retries or dead-letter queues to ensure that whatever didn't get acknowledged can be retried and completed. We use it mainly for retries.

I think the tool is very reliable. With the dead-letter queues, we can ensure even if a third-party service or an e-commerce website over which we have no control goes down for some time, we can make sure that our workflows remain unaffected and, eventually, we have reached the state where we expect to be. We probably use Amazon SQS in almost all of our microservices, and there are plenty of them, more than a hundred. It is pretty easy to use and do testing on Amazon SQS. It is pretty easy to integrate any new use case or service, and it is easy to sort of manage. AWS makes it very easy to manage and change the resource requirements for a particular Amazon SQS queue. The tool is pretty easy to use.

I primarily use SQL Server for messaging services, and I need to offer loose couplings. SQS is handy for offloading non-urgent tasks that can be reverted later. I use it as a queue management service for deferring processing or ensuring important messages are preserved in the queue before being processed by Lambda integrators. Lambda can pull messages from the queue, process them to completion, and then erase them, providing reliable communication.

The most valuable feature for me is the variety of queues offered, such as the standard and FIFO queues, providing reliable communication. FIFO queues ensure a message is processed once, preventing duplicate processing. This product is serverless, managed, and scalable, with benefits similar to Lambda Compute. It offers high scalability, availability, and protection against failures, eliminating my need for EC2 infrastructure for messaging processing. My campus has become cashless, with all transactions digitized and utilizing AWS for scalability. The migration to the cloud has satisfied our students, staff, and finance department, with a reduced responsibility. There are no concerns regarding the solution's cost.

I have been heavily using Amazon SQS for the last more than four years in serverless and decoupled solutions. 

We use it in workflows like order creation, where the order creation task is queued, allowing consumers to pull and process the information in batches. 

SQS helps in loose coupling between producers and consumers and is valuable for storing failed record processing through DLQs.

One of the most valuable features of Amazon SQS is its ability to handle large-scale data with millions of records per queue. The scale it manages is quite impressive. 

Additionally, features such as message retention up to 14 days are impactful, as they allow for the processing of messages if consumer systems are slow or unavailable. Integration capabilities with services like EC2, Lambda, EventBridge, and SNS for a fan-out pattern further enhance its functionality.