Event-Driven Design: Choosing Between SNS, SQS, and EventBridge

SNS, SQS, and EventBridge all move messages between decoupled components, which is exactly why it's easy to reach for the wrong one. This article draws the lines. It covers what problem each service is built for, a concrete scenario for each, and a comparison table across message type, delivery model, routing, and durability.

The short version: SNS is push-based pub/sub, so one message fans out to many subscribers (HTTP/S, email, SMS, AWS targets). It's good for real-time notifications, like a news platform broadcasting a breaking story. SQS is a durable queue that buffers work so a slow consumer doesn't get overwhelmed, with Standard (at-least-once) and FIFO (exactly-once) modes. Think of an order-processing pipeline. EventBridge is an event bus that routes events to targets by rule and pattern, wiring together AWS services, SaaS, and custom sources. For example, a shipment-status change that triggers a few Lambdas.

Key takeaways

• Match the service to the problem shape: fan one event to many (SNS), absorb and smooth a workload (SQS), route many event types by rule (EventBridge)
• SNS alone can drop a message if no subscriber is there: put SQS queues behind SNS so each consumer has a buffer to retry from
• EventBridge plus SQS: rule-based routing into a queue a worker drains at its own pace

Who this is for

Developers designing an event-driven or decoupled system on AWS who need to pick between these three, or combine them, with intent. It's conceptual rather than code-heavy. This is the decision framework, not an implementation tutorial, and it doesn't drill into FIFO ordering, dead letter queues, or message filtering.

The full comparison, with the decision table and the per-service scenarios, is on DEV.to.