AWS SQS Case Study

Hey guys ! Today we are going to look one of the most common service SQS (Simple Queue Service) available in AWS cloud which is very often used depending on our use cases. Let's have a brief look at that particular service...…..

What is AWS SQS ?

• Amazon Simple Queue Service (SQS) is a fully managed message queuing service that enables you to decouple and scale microservices, distributed systems, and server less 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.
• Getting started with SQS in minutes using the AWS console, Command Line Interface or SDK of your choice, and three simple commands.

SQS Use Cases

Work Queues

• Decouple components of a distributed application that may not all process the same amount of work simultaneously.

Buffer and Batch Operations

• Add scalability and reliability to the?architecture and smooth out temporary volume spikes without losing messages or increasing latency

Request Offloading

• Move slow operations off of interactive request paths by enqueueing the request.

Fan-out

• Combine SQS with SNS to send identical copies of a message to multiple queues in parallel for simultaneous processing.

Auto Scaling

• SQS queues can be used to determine the load on an application, and combined with Auto Scaling, the EC2 instances can be scaled in or out, depending on the volume of traffic

How SQS Queues Works

• SQS allows queues to be?created, deleted and messages can be sent and received from?it
• SQS?queue retains messages for four days, by default.
• Queues can be configured to retain messages for 1 minute to 14 days after the message has been sent.
• SQS can delete a queue without notification if any action hasn’t been performed on it for 30 consecutive days.
• SQS allows the deletion of the queue with messages in it

Advantages of message queue

• Asynchronous: Queue it now, run it later.
• Decoupling: Separates a application logic.
• Resilience: Won't take down your whole application if part of it fails.
• Redundancy: Can retry job if they fail.
• Guarantees: Makes sure that jobs will be processed.
• Scalable: Many workers can process individuals jobs in queue.
• Profiling: Can aid in identifying performance issue.

Message Lifecycle

1. Component 1 sends Message A to a queue, and the message is redundantly distributed?across the SQS servers.
2. When Component 2 is ready to process a message, it retrieves messages from the queue,?and Message A is returned. While Message A is being processed, it remains in the queue but?is not returned to subsequent receive requests for the duration of the visibility timeout.
3. Component 2 deletes Message A from the queue to avoid the message being received and?processed again once the visibility timeout expires.

SQS Design Patterns

Priority Queue Pattern

1. Use SQS to prepare multiple queues for the individual priority levels.
2. Place those processes to be executed immediately (job requests) in the high priority queue.
3. Prepare numbers of batch servers, for processing the job requests of the queues, depending on the priority levels.
4. Queues have a message “Delayed Send” function, which can be used to delay the time for starting a process.

1. Enqueue job requests as SQS messages.
2. Have the batch server dequeue and process messages from SQS.
3. Set up Auto Scaling to automatically increase or decrease the number of batch servers, using the number of SQS messages, with Cloud Watch, as the trigger to do so.

Real benefits of SQS triggers which makes it more useful

• SQS triggers are a game changer. They allow more robust decoupled, scalable, event-driven server less architectures, and they also trigger some awesome side effects when used properly. Here are my top five:
• SQS triggers allow me to reduce my infrastructure footprint.?In many cases, my workarounds included the use of alternate services, sometimes with reduced functionality, sometimes augmented with additional code and services to bridge the functionality gap. Where I was once using multiple services (like Kinesis Data Streams and SQS or SNS and SQS), I can now use just a single SQS queue and achieve the same functionality.
• SQS?triggers cost less than equivalent workarounds.?Replacing multiple services with a single one will reduce cost, both in terms of time and money. You’ll spent less time implementing and debugging costly workarounds and less money on redundant services and features.
• SQS?triggers make things simpler.?Removing infrastructure, services, and code means fewer moving parts. Fewer moving parts means you’ll have an easier time maintaining, debugging, tracing, logging, and monitoring these systems. In my case,?SQS?triggers acted as a drop-in replacement, so I was able to realize these benefits immediately.
• SQS triggers improve fault tolerance.?OK, I’ll admit, I took the lazy route previously and didn’t completely match the functionality I can now get with SQS events. Failed execution meant tasks were dropped on the floor with no retry attempts. Lambda support for SQS triggers provides built-in retry functionality, with additional resilience and debuggability obtained using DLQs.
• SQS triggers make end users happier.?All of these benefits lead to happier users. Most of my systems are personal projects, but still, it’s nice to know that the end-user experience (even if it is just me) will be improved. I can spend less time dealing with infrastructure problems and more time on projects.

That was all about amazon SQS service. Hope you liked this article ??????

##### Thanks for reading this Article #####