SQS-stands for Simple Queue Service-is a service operated by AWS to handle queueing of messages.
One service sends messages in a queue and another service receives those messages. It can be used for a whole range of purposes.
SQS frees developers from the worries of setting up and managing a queue structure as a managed service. The service will provide everything required out of the box and scale seamlessly to meet the demand.
This can be a great match for projects working on a tight schedule as well as for development teams small and medium in scale.
What is it used for
SQS is also used for the complement of distributed backend services. Instead of making one service communicate directly with another, the contact may be intermediated by a queue.
Another common use for queues is to handle malfunctions in the scalability of services. Bottlenecks can become a problem when a service depends on another service that can not scale to the same level or as quickly as the first one. Having a queue between A and B is useful in such situations because the queue can handle peak demand from A, and send messages at a slower rate with which B can cope.
How it works
In another post, we’ve already discussed the large structure of the message queues. SQS builds on these ideas and offers an API that can be used by developers to connect with the service.
The main actions in high-level are:
- Send Message: A service sends a request to a queue that is available for use by another service.
- Receive Message: Another service can request to receive pending messages in the queue;
- Delete Message: Upon proper processing of a message, the user can remove it from the queue;
SQS does not operate as a database, so the user can not decide which message from the queue to receive. However, it can decide how many messages it wants to receive at any given time.
After receiving a message SQS will temporarily delete it from the queue. This is to stop eating it twice (although in some situations it can still happen-see the section below). The message will be hidden for a certain time, and the user will have the ability to process it and later erase it from the list.
If the message is not removed after the timeout duration of visibility, it will go back to the queue and will be received in future requests. The timeout interval for visibility can be adjusted.
Types of Queues
There are two different types of queues in SQS: FIFO and Standard.
SQS can send messages offline in the Regular Queue. It means a message that was sent later can be sent to a customer first. It can also in certain instances convey the same message more than once. This type of queue leverages the benefits of low-consistency distributed systems that drive down costs. This is the cheapest choice of SQS as a result.
Form FIFO follows a pattern First-in, First-out. It delivers messages in the exact order in which they were sent, and each message is only delivered once. Despite being 25 percent more costly than Standard queues, FIFO is often required for projects requiring precision and high consistency properties for their queues.
The scalability capacities are another distinction between the two forms of queues. Standard queues allow an unlimited number of transactions per second, which FIFO can manage up to 3,000 messages per second, although the AWS allows can raise this cap.
Hope this blog is helpful for you, Keep Learning!!!!!