CloudArcade

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 tour

1. 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 queue

2. 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 ARN

3. 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 shipping

Practice, 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.

Continue with another AWS learning guide