What the exam asks
- Absorb spikes or stop losing requests → SQS between the tiers.
- Strict order and no duplicates → SQS FIFO, with a message group ID per entity so processing stays parallel.
- One event, several independent consumers → SNS fan-out to SQS queues, with filter policies for subsets.
- React to AWS service events or SaaS events, or route by content across accounts → EventBridge.
- Schedules → EventBridge Scheduler. Point-to-point integration with filtering and enrichment → EventBridge Pipes.
- An existing JMS, AMQP, MQTT or STOMP application with no code changes → Amazon MQ.
- Tuning: duplicate processing → visibility timeout. Empty receives → long polling. Poison messages → dead-letter queue. Scaling workers → backlog per instance.
Core ideas
SQS standard vs FIFO
| Standard | FIFO | |
|---|---|---|
| Delivery | At least once (occasional duplicates) | Exactly-once processing (deduplication within a 5-minute interval) |
| Ordering | Best effort | Strict within a message group ID |
| Throughput | Nearly unlimited | Lower (high throughput mode raises it) |
| Typical use | Work queues, buffering, decoupling | Payments and commands that must not repeat or run out of order |
FIFO ordering applies per message group. If every message uses the same group ID, the whole queue is processed one message at a time. A group per customer or account keeps order where it matters and allows parallel processing everywhere else. Deduplication uses either a deduplication ID that you set or content-based deduplication, which hashes the message body. If a retry changes the body, only an explicit deduplication ID catches the duplicate.