Guided architecture tour · 5–7 min
SNS and SQS architecture
Choose fan-out, give consumers independent queues, and distinguish SNS delivery from competing queue workers.
This tour teaches architecture decisions. Its services are not provisioned in the emulator.
Play this architecture tour1. Choose fan-out
Both billing and shipping must receive each order event independently.
Which layout expresses that requirement?
An SNS topic with separate billing and shipping queue subscriptions.
Workers on one queue compete for messages. Separate subscribed queues give each system its own copy and processing pace.
The model branches from one topic to two independent queues.
Publish → SNS topic → billing queue
→ shipping queue2. Permit topic delivery
The queue subscription exists, but the queue does not allow the topic to send messages.
Which configuration needs attention?
The SQS queue policy scoped to the SNS topic.
A subscription and destination permission are separate concerns. Scope the permission to the intended topic.
The destination allows the intended topic to send messages.
SQS policy: allow sns.amazonaws.com → sqs:SendMessage
Condition: aws:SourceArn equals the intended topic ARN3. Keep listeners independent
Shipping becomes slow while billing is healthy.
Why keep separate subscriber queues?
Each consumer retains and processes its own backlog.
Separate queues isolate processing pace. Each consumer still needs retry and duplicate-handling logic.
Billing continues while the shipping backlog waits for shipping workers.
Billing queue → healthy worker
Shipping queue → growing backlog → scale or repair shippingPractice, then check your understanding
In the interactive tour, make each decision before seeing the outcome. Wrong answers receive coaching, and replay gives you a fresh attempt without duplicating earned XP.
Read the official AWS documentation for service behavior and production details.