Case Study on Amazon SQS

Gaurav Tank
5 min readOct 22, 2021

Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and serverless applications. SQS eliminates the complexity and overhead associated with managing and operating message-oriented middleware and empowers developers to focus on differentiating work. Using SQS, you can send, store, and receive messages between software components at any volume, without losing messages or requiring other services to be available. Get started with SQS in minutes using the AWS console, Command Line Interface or SDK of your choice, and three simple commands.

SQS offers two types of message queues. Standard queues offer maximum throughput, best-effort ordering, and at least one delivery. SQS FIFO queues are designed to guarantee that messages are processed exactly once, in the exact order that they are sent.


There are three main parts to a distributed messaging system: the components of your distributed system, your queue (distributed on Amazon SQS servers), and the messages in the queue.

In the following scenario, your system has several producers (components that send messages to the queue) and consumers (components that receive messages from the queue). The queue (which holds messages A through E) redundantly stores the messages across multiple Amazon SQS servers.

Benefits of using Amazon SQS

  • Security — You control who can send messages to and receive messages from an Amazon SQS queue.
  • Server-side encryption (SSE) lets you transmit sensitive data by protecting the contents of messages in queues using keys managed in AWS Key Management Service (AWS KMS).
  • Durability — For the safety of your messages, Amazon SQS stores them on multiple servers. Standard queues support at least one message delivery, and FIFO queues support exactly one message processing.
  • Availability — Amazon SQS uses redundant infrastructure to provide highly concurrent access to messages and high availability for producing and consuming messages.
  • Scalability — Amazon SQS can process each buffered request independently, scaling transparently to handle any load increases or spikes without any provisioning instructions.
  • Reliability — Amazon SQS locks your messages during processing so that multiple producers can send and multiple consumers can receive messages at the same time.
  • Customization — Your queues don’t have to be exactly alike — for example, you can set a default delay on a queue. You can store the contents of messages larger than 256 KB using Amazon Simple Storage Service (Amazon S3) or Amazon DynamoDB, with Amazon SQS holding a pointer to the Amazon S3 object, or you can split a large message into smaller messages.

AWS SQS Features

Confidential secure data: The SSE or Server-side encryption facility under SQS enables transmitting highly secure, sensitive, and confidential data. It provides the Key management services as a protection to the messages present within the queues.

Less data wastage: The Amazon SQS makes sure the messages sent to the components are not lost and stay secure. This message data is stored on different general/standard queues.

Message Locking facility: Amazon SQS helps in message locking when the receiver gets in during the process. It makes the other producers send the message to the receivers securely. In case, the processing of messages get fail then the lock will expire and the message will be available again for processing.

Message retain: The message can be retained within the queues up to a maximum period of 14 days.

Queue Sharing: AWS Simple queue service offers queue sharing securely either anonymously or with a secure Amazon account. This sharing can be put on restriction by the time it is shared in a day and also through the IP address of the system.

Unlimited data: Users can generate SQS queues using an unlimited message within any region.

Work Queues: It allows separating components of an allocated application. So that may not all process the same quantity of work in parallel.

Buffer and group Operations: It helps to add scalability and reliability to the user’s system architecture. Further, it smoothly deals with the data without losing messages or enhancing latency.

Request Offloading: It allows moving slow operations of the interactive request paths by adding a queue of similar items for the request.

Also, Simple Queue Service provides high scalability and resiliency of the messages. It helps to save the messages from failure and process them securely.

RedBus: The Case Study

RedBus is an Indian online bus ticketing platform providing ticket booking facilities through its website, iOS, and Android mobile apps. Headquartered in Bengaluru, India, it connects bus travelers with a network of over 2500 bus operators, across India, countries in South East Asia, and Latin America. The company also offers software, on a Software as a Service (SaaS) basis, which gives bus operators the option of handling their ticketing and managing their inventories. To date, the company says they have sold over 30 million bus tickets and has more than 1750 bus operators using the software to manage their operations

Challenges Faced by the RedBus:-

The company previously ran its operations from a traditional data center by purchasing and renting its systems and infrastructure. In addition to the expense, several logistical problems evolved from this arrangement. The biggest problem was that the infrastructure could not effectively handle processing fluctuations, which had a negative impact on productivity. Additionally, the procurement of servers or upgrading the server configuration was an extremely time-consuming endeavor.

RedBus receives complaints from customers mainly regarding Refunds, Cancellations, Operator queries, etc… The process of classifying these emails and redirecting them to the respective customer service agents/queue becomes a humongous task. This also increases during peak days (especially holidays and weekends). Over time, redBus realized that a better solution was imperative — a solution that offered scalability to handle the company’s processing fluctuations. redBus looked to Amazon Web Services (AWS) for a solution.