SNS and SQS integration pattern (fan-out) in AWS - Time & Space Complexity
When using SNS to send messages to multiple SQS queues, it's important to understand how the number of queues affects the work done.
We want to know how the number of API calls grows as we add more queues to the fan-out.
Analyze the time complexity of sending a message from SNS to multiple SQS queues.
# Create SNS topic
aws sns create-topic --name MyTopic
# Create multiple SQS queues
aws sqs create-queue --queue-name Queue1
aws sqs create-queue --queue-name Queue2
# ... more queues
# Subscribe each SQS queue to the SNS topic
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:MyTopic --protocol sqs --notification-endpoint arn:aws:sqs:region:account-id:Queue1
aws sns subscribe --topic-arn arn:aws:sns:region:account-id:MyTopic --protocol sqs --notification-endpoint arn:aws:sqs:region:account-id:Queue2
# Publish a message to SNS topic
aws sns publish --topic-arn arn:aws:sns:region:account-id:MyTopic --message "Hello"
This sequence sets up SNS to send one message to many SQS queues, creating a fan-out pattern.
Look at what happens repeatedly when a message is published.
- Primary operation: SNS delivers the message to each subscribed SQS queue.
- How many times: Once per subscribed queue.
As you add more queues, SNS sends the message to each one separately.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 10 message deliveries |
| 100 | 100 message deliveries |
| 1000 | 1000 message deliveries |
Pattern observation: The number of message deliveries grows directly with the number of queues.
Time Complexity: O(n)
This means the work grows linearly as you add more queues to the fan-out.
[X] Wrong: "Publishing one message to SNS sends it once, no matter how many queues are subscribed."
[OK] Correct: SNS sends a separate copy of the message to each subscribed queue, so the total work increases with the number of queues.
Understanding how message fan-out scales helps you design systems that handle growing workloads smoothly.
"What if we replaced SQS queues with HTTP endpoints subscribed to SNS? How would the time complexity change?"
Practice
Solution
Step 1: Understand SNS role in fan-out
SNS publishes messages to multiple subscribers simultaneously.Step 2: Understand SQS role in fan-out
Each SQS queue receives and holds messages independently for processing.Final Answer:
To send the same message to multiple queues for parallel processing -> Option AQuick Check:
SNS fan-out = multiple queues get same message [OK]
- Thinking SNS sends to only one queue
- Confusing message storage with deletion
- Assuming messages are deleted immediately
Solution
Step 1: Identify correct AWS CLI command
The AWS CLI command to subscribe is 'aws sns subscribe'.Step 2: Check parameters for SQS subscription
Use '--protocol sqs' and '--notification-endpoint' with the queue ARN.Final Answer:
aws sns subscribe --topic-arn <topic-arn> --protocol sqs --notification-endpoint <queue-arn> -> Option AQuick Check:
Subscribe SQS to SNS uses 'aws sns subscribe' with protocol sqs [OK]
- Using 'aws sqs subscribe' which does not exist
- Confusing queue URL with queue ARN
- Using wrong command like 'aws sns add-queue'
Solution
Step 1: Understand SNS fan-out delivery
SNS sends a copy of the message to each subscribed queue.Step 2: Understand SQS message handling
Each queue holds its own copy until processed or deleted.Final Answer:
The message appears in both queues independently, waiting to be processed. -> Option CQuick Check:
Fan-out means each queue gets its own message copy [OK]
- Thinking message goes to only one queue
- Assuming message is deleted immediately
- Believing message duplicates in one queue only
Solution
Step 1: Check subscription confirmation
SQS subscriptions to SNS require confirmation to activate delivery.Step 2: Understand SNS delivery behavior
Without confirmation, SNS does not send messages to that queue.Final Answer:
The second queue's subscription is not confirmed -> Option BQuick Check:
Unconfirmed subscription blocks message delivery [OK]
- Assuming SNS sends to only one queue
- Blaming message size without checking subscription
- Thinking message deletion affects delivery
Solution
Step 1: Use SNS fan-out to send messages to all queues
Subscribing all three SQS queues to the SNS topic ensures each gets the message.Step 2: Enable dead-letter queues and set retention
Dead-letter queues catch failed messages; retention ensures messages stay until processed.Final Answer:
Subscribe all three SQS queues to the SNS topic, enable dead-letter queues for each, and set appropriate message retention -> Option DQuick Check:
Fan-out + DLQ + retention = reliable, no message loss [OK]
- Skipping dead-letter queues causing message loss
- Using one queue for all processing causing bottlenecks
- Not subscribing all queues to SNS topic
Ready to prove it?
Pass the test and this pattern moves unknown
