AWS SQS service working
What is SQS
Basically SQS is a web service that gives you access to a message queue that can be used to store messages while waiting for a consumer to process them.
SQS is a distributed queue system and a queue is a temporary repo for messages that are waiting to be processed.
What Are the Main Benefits of Amazon SQS?
Security: You control who can send messages to and receive messages from an Amazon SQS queue.
Server-side encryption (SSE): It lets you transmit sensitive data by protecting the contents of messages in queues using keys managed in AWS Key Management Service (AWS KMS).
Durability: To ensure the safety of your messages, Amazon SQS stores them on multiple servers. Standard queues support at-least-once message delivery, and FIFO queues support exactly-once 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.
How does SQS work?
SQS provides an API endpoint to submit messages and another endpoint to read messages from a queue. Each message can only be retrieved once, and you can have many clients submitting messages to and reading messages from a queue at the same time.
The messages that SQS handles can be unformatted strings, XML or JSON. Because SQS guarantees “exactly once” delivery, and because you can concurrently submit messages to and read messages from a given queue, SQS is a good option for integrating multiple independent systems.
You might well be asking: why use SQS if you can have an internal HTTP API for each service? While HTTP APIs are an accessible way to expose software systems to external users, it’s not the most efficient mechanism when it comes to integrating purely internal systems. A messaging queue is more lightweight. In particular, SQS also handles things like automated retries, preserving queue state across multiple availability zones in AWS, and keeping track of expiration timeouts on all messages.
BENEFITS OF USING SQS
For Serverless developers, using SQS generally provides a wealth of benefits, which you can read about below.
Scalability
Your SQS queues scale to the volume of messages you’re writing and reading. You don’t need to scale the queues; all the scaling and performance-at-scale aspects are taken care of by AWS.
What is SQS used for?
The most common ways to use SQS, and of course other messaging systems, in cloud applications are:
Decoupling microservices.
In a microservice architecture, messages represent one of the easiest ways to set up communication between different parts of the system. If your microservices run in AWS, and especially if those are Serverless services, SQS is a great choice for that aspect of the communication.
Sending tasks between different parts of your system.
You don’t have to be running a microservices-oriented application to take advantage of SQS. You can also use it in any kind of application that needs to communicate tasks to other systems.
Distributing workloads from a central node to worker nodes.
You can frequently find messaging systems in the flows of distributed large workloads like map-reduce operations. For these kinds of operations, it’s essential to be able to maintain a queue of all the tasks that need to be processed, efficiently distribute the tasks between the machines or functions doing the work, and guarantee that every part of the work is only done once.
Scheduling batch jobs.
SQS is a great option for scheduling batch jobs for two reasons. First, it maintains a durable queue of all the scheduled jobs, which means you don’t need to keep track of the job status — you can rely on SQS to pass the jobs through and to handle any retries, should an execution fail and your batch system returns the message to the queue. Second, it integrates with AWS Lambda; if you’re using AWS Lambda to process the batch jobs, SQS automatically launches your Lambda functions once the data is available for them to process.
Some important concepts associated with SQS are-
- SQS Visibility Timeout-
A period of time that prevent other consumers from processing the message is called SQS visibility timeout
2. Deadletter Queue:
Dead-letter queue helps in handling message failure as it isolates the failure messages such that we can determine why the processing didn’t succeed
Some important concepts associated with SQS are-
- SQS Visibility Timeout-
A period of time that prevent other consumers from processing the message is called SQS visibility timeout
2. Deadletter Queue:
Dead-letter queue helps in handling message failure as it isolates the failure messages such that we can determine why the processing didn’t succeed
Go to SQS console, click on Get- Started Now. You will see below UI. Type the Queue name, let’s say TestQueue & Queue Type: Standard.
Go downside & click on Configure Queue.
Keep these values for Attributes of your Queue & click create Queue.
You Queue is created now.
Now click on Queue & Quick Actions then click on Send Message. Type your message & click on send Message.
As you can see there is 1 message available in your queue.
Now let’s check the message, click on Quick action then view/delete message & click on start polling message.
Now you will be able to see you message.
