Developing Solutions with Amazon SQS & SNS Flashcards
What is Amazon SQS
Amazon Simple Queue Service (Amazon SQS) is a web service that gives you access to a message queue that can be used to store messages while waiting for a computer to process them.
What is the disadvantage of not having queue between producer and consumer
Interdependency between producer and consumer creates a tightly coupled system. The disadvantage with a tightly coupled system is that it is not fault tolerant. If any one component in our system fails, the entire system will fail.
what are the different queue types
Standard queues:
- More than one copy of a message might be delivered
- Messages may be delivered out of order
FIFO queues (First-In-First-Out):
- No duplicated messages
- Order is guaranteed
- Limited to 300 transactions per second
What is the visibility timeout
Period of time during which Amazon SQS prevents other consumers from receiving and processing the message. During this period, a message is invisible to the rest of your application after an application component gets it from the queue.
The default value is 30 seconds, max 12 hours.
SQS: When is message deleted?
Amazon SQS automatically deletes messages that have been in a queue for more than maximum message retention period.
When you receive the message, you must delete it from the queue to acknowledge that you processed the message and no longer need it.
To delete a message, you must provide the most recently received receipt handle when you request to delete the message
Difference between short polling and long polling
Short polling returns a response immediately, even if the queue being polled is empty. It’s the default behavior of Amazon SQS queues.
Long polling does not return a response until a message arrives in the queue, or the long poll times out. Unless the connection times out, the response to the ReceiveMessage request contains at least one of the available messages.
If you decide to implement long polling with multiple queues, we recommend that you use one thread for each queue
SQS : what are the main identifiers for queue & messages?
- Queue URL
When creating a new queue, you must provide a queue name that is unique within the scope of all your queues. Amazon SQS assigns each queue you create an identifier called a queue URL, which includes the queue name and other components that Amazon SQS determines. - Message ID
For each message, Amazon SQS returns a system-assigned message ID in the SendMessage response - Receipt Handle
Each time you receive a message from a queue, you receive a receipt handle for that message. If you receive a message more than once, each time you receive it, you get a different receipt handle.
What is the dead-letter queue
A dead-letter queue (DLQ) is an Amazon SQS queue that you configure to receive messages from other Amazon SQS queues, referred to as “source queues”. Typically, you set up a DLQ to receive messages after a maximum number of processing attempts has been reached. DLQ provides the ability to isolate messages that could not be processed.
SQS: How can we share a queue?
A developer associates an access policy statement (specifying the permissions being granted) with the queue to be shared.
Amazon SQS in each region is totally independent in message stores and queue names; therefore, the messages cannot be shared between queues in different regions.
SQS: How does the server-side encryption work?
Server-side encryption (SSE) encrypts the body of the message, but does not touch the queue metadata, the message metadata, or the per-queue metrics.
Adding encryption to an existing queue does not encrypt any backlogged messages. Similarly, removing encryption leaves backlogged messages encrypted.
You can use the AWS managed customer master key (CMK) which is unique for each customer and region, or you can create and manage your own keys.
Five Amazon 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 your architecture and smooth out temporary volume spikes without losing messages or increasing latency. - Request offloading
Move slow operations off of interactive request paths by enqueuing the request. - Auto Scaling
You can use Amazon SQS queues to help determine the load on an application, and when combined with Auto Scaling, you can scale the number of Amazon EC2 instances out or in, depending on the volume of traffic. - Fan-out
Combine Amazon SQS with Amazon SNS to send identical copies of a message to multiple queues in parallel for simultaneous processing.
What is Amazon SNS
Amazon Simple Notification Service (Amazon SNS) is a web service that makes it easy to set up, operate, and send notifications from the cloud. Amazon SNS follows the “publish-subscribe” (pub-sub) messaging paradigm, with notifications being delivered to clients using a “push” mechanism that eliminates the need to periodically check or “poll” for new information and updates.
Describe the use case Fan Out with SNS and SQS
In a fan-out scenario, an Amazon SNS message is sent to a topic and then replicated and pushed to multiple Amazon SQS queues, HTTP endpoints, or email addresses.
This allows for parallel asynchronous processing.
For example, you could develop an application that sends an Amazon SNS message to a topic whenever an order is placed for a product. Then, the Amazon SQS queues that are subscribed to that topic would receive identical notifications for the new order.
Describe SNS operation CreateTopic
The CreateTopic request creates a topic to which notifications can be published. Users can create a maximum of 3000 topics. This action is idempotent, so if the requester already owns a topic with the specified name, that topic’s ARN is returned without creating a new topic. The response from the CreateTopic request contains the Amazon Resource Name (ARN) of the created topic.
Describe SNS operation Subscribe
The Subscribe request prepares to subscribe an endpoint by sending the endpoint a confirmation message. To actually create a subscription, the endpoint owner must call the ConfirmSubscription action with the token from the confirmation message. Confirmation tokens are valid for three days. The response of the Subscribe request includes the ARN of the subscription, if the service was able to create a subscription immediately (without requiring endpoint owner confirmation)
