Loose Coupling
- almost always better
- you never want one EC2 instance talking to another instance -> you want some kind of managed service acting as the go between
SQS
Simple queue service
- fully managed
- poll-based messaging
Simple Notification Service
- to deliver notifications to an endpoint
- to deliver text messages or emails
API Gateway
- a fully managed service that makes it easy for developers to create, publish, maintain, monitor and secure APIs at any scale
SQS Producer
- writes the message to the queue
SQS Consumer
- pickups up the message when they are ready
SQS Setting - Delivery Delay
- default: 0
- up to 15 min
- queue holds the message
SQS Setting - Message Size
- up to 256 KB of text in any format
SQS & SNS Setting - Encryption
- default: messages are encrypted in transit
- optional: can add encryption at rest
SQS Setting - Message Retention*
- default: 4 days
- minimum: 1 minute
- maximum: 14 days
SQS Setting - Long Polling*
API connects and waits (not selected by default)
- always choose long polling on the exam
SQS Setting - Short Polling*
API connects and gets a message and disconnects
- lots of overhead
- costly
- don’t choose on exam
SQS Setting - Queue Depth*
- this can be a trigger for autoscaling as the messages back up
- Cloud Watch tells EC2 instance to spin up to address the queue
SQS Visibility Timeout*
- default timeout: 30 seconds
- once the consuming service attempts to download a message from the queue, it is locked for X seconds so no one else can see it
- If the backend fails to process the message and tell the queue it’s good, the message will re-appear in the queue
Otherwise, if the backend sends back and all good message, then it is deleted from the queue
Dead Letter Queues
- when a backend processes a message but the processing fails, it goes into the queue and gets stuck in a loop, instead, send it to a dead letter queue if they’ve reached the maximum # of re-tries
- same limits as regular SQS queue - max: 14 days
What is the only way to take a message from a queue and temporarily set it aside?
Dead Letter Queue
Why do you need to set an alarm on a Dead Letter Queue?
so you can catch it before something goes off the rails
How to create a Dead Letter Queue
1) Need to create the dead letter queue before you create your main queue
2) then create the main queue and specify the dead letter queue and set the maximum receives = maximum retries
Can SNS use dead letter queues?*
Yes, both SQS and SNS can use them
Standard SQS Queues
- SQS offers best effort ordering
- occasionally you might get a message twice
- nearly unlimited transactions per second
- cheaper
FIFO Queues
- proper ordering
- there will be no duplicates
- 300 messages per second (slower)
- more costly
- queue name must end in .fifo
- requires: a message group ID and a message deduplication ID
Fifo Message Group ID
- ensures messages are processed one by one
- all messages in the group are downloaded together
SNS Push Based messaging
- you have to be ready at any point in time to receive a message
- proactively delivers messages to the endpoints subscribed to it
SNS Setting - Subscribers*
- Kinesis Data Firehose
- SQS
- Lambda
- HTTP(s)
- SMS
- platform application endpoint
