SQS & SNS Messaging

The plain-language idea

SQS (Simple Queue Service) is a queue: a producer drops a message in, and exactly one consumer picks it up, processes it, and deletes it. SNS (Simple Notification Service) is publish/subscribe: a producer publishes one message to a topic, and every subscriber attached to that topic gets its own copy. That's the whole distinction — one consumer per message versus many.

The reason either exists at all is decoupling. Without a queue, a producer calling a slow or occasionally-down consumer directly means the producer's request hangs or fails along with it. Drop a message in SQS instead, and the producer's job is done the instant the message is accepted — the consumer reads at its own pace, and a consumer that's temporarily overwhelmed or offline just means messages wait in the queue instead of the producer failing.

See it in a real thing: SNS fanning out to three SQS queues

An OrderPlaced event needs to trigger billing, shipping, and analytics — three independent systems that each need to know, but shouldn't block each other or the checkout flow.

OrderPlaced --publish--> SNS topic "orders"
                             |-- subscribe --> SQS: billing-queue
                             |-- subscribe --> SQS: shipping-queue
                             +-- subscribe --> SQS: analytics-queue

Checkout publishes OrderPlaced once, to the SNS topic "orders" — it knows nothing about billing, shipping, or analytics.

BackNext

The checkout service publishes once, to the topic, and knows nothing about billing, shipping, or analytics individually. SNS delivers a copy of that message into each subscribed SQS queue, and each queue is then consumed independently — the shipping worker being slow or temporarily down has zero effect on billing processing, because they're reading from entirely separate queues. This fan-out pattern (SNS topic fanning out to multiple SQS queues) is the standard way to get "one event, several independent reactions" without hardcoding those reactions into the publisher or making them block each other.

What people usually miss

Watch out

• SNS does not queue or retry on its own the way SQS does. A raw HTTP or email subscriber that's down when SNS publishes can lose that message; SQS subscriptions survive because the message sits durably in the queue until a consumer reads it, which is a real reason SNS-to-SQS fan-out is the common pattern rather than SNS-to-application-directly.
• A message isn't removed from SQS just because a consumer received it. It becomes invisible to other consumers for a visibility timeout window and is only actually deleted once the consumer explicitly acknowledges success — if the consumer crashes mid-processing without deleting it, the message reappears for another consumer to try.
• A dead-letter queue (DLQ) isn't automatic. It has to be explicitly configured with a max-receive-count, after which a message that keeps failing gets moved out of the main queue instead of being retried forever or silently dropped — without one, a single poison message can loop indefinitely and mask the fact that something's actually broken.
• Standard queues can deliver a message more than once. This isn't a bug to work around defensively as an edge case — it's the documented contract, and any consumer built against a Standard queue has to be written idempotently (safe to process the same message twice) from the start, not patched later.

Why this matters in interviews

"When would you reach for SQS versus SNS?" is a common systems-design question, and the sharp answer isn't a memorized rule — it's recognizing that the real question is "should exactly one thing handle this, or should every interested thing hear about it," with fan-out (SNS publishing into several SQS queues) as the pattern that gets both at once.