Messaging¶

Features	SQS	SNS	EventBridge
Type	1:1	1:M	M:M
Purpose	Async holding area	High Throughput	Services Integration
Ordering	Optional	?	?
Read	Polling (unless Lambda)	BP Use SQs as front-end

SQS Simple Queuing Service¶

One message can be read by only one subscriber
Standard Queues: does not guarantee order, at least once delivery
- Messages retained for up to 14 days
- If job doesn’t finish within Visibility Timeout (Max 12h), it will appear again
- Long polling (wait) or short polling (returns immediately)
FIFO queues: FIO order guarantee, exactly-once delivery
Pull-based delivery
redrive policy specifies the source queue, dead letter queue and conditions under which SQS moves messages to dead letter queue
BP: In order to use fan-out combine it with SNS
BP: When using with lambda service (which polls SQS)
- set lambda concurrency to 5+
- SQS visibility timeout to 6 times lambda timeout
- use dead letter queue

PubSub, multiple subscribers using topics
Used for decoupling services, unlike SQS, the publisher doesn't need to know about the subscribers
Automatically stored redundantly on multiple AZ
not meant for long term message storage
- BP: Setup a SQS for each subscriber which can hold messages longer
Subscribers: HTTP, HTTPS, Email, Email (JSON), Lambda, Application, SQS
Subscription filters allow subscribers to filter messages they are interested in

components: Event Bus, Events, Rules and Targets
- Rules specify which targets receive events
A rule can have up to 5 targets, but the same event can be matched by more than 1 rule
An SNS topic can be specified as a target
supports filtering to listen in only the interested events
works very similar to SNS with integrations with:
- AWS services (e.g. EC2 instance spins up)
- External services (e.g. Shopify, PagerDuty, DataDog etc)