EventBridge is like a smart, programmable router for events, SNS is a broadcast system, and SQS is a queue for individual messages.
Let’s watch EventBridge in action. Imagine you have a new order come into your e-commerce system. This order event needs to be processed by several different downstream services: a notification service to email the customer, an inventory service to decrement stock, and a fulfillment service to start packing.
Here’s how you might set that up in AWS:
First, your order service publishes an event to EventBridge. This event could look like this JSON:
{
"source": "com.my-ecommerce-app.orders",
"detail-type": "New Order",
"detail": {
"orderId": "ORD12345",
"customerId": "CUST9876",
"items": [
{"sku": "ABC-101", "quantity": 2},
{"sku": "XYZ-202", "quantity": 1}
],
"totalAmount": 150.75
},
"region": "us-east-1",
"account": "123456789012"
}
Then, you create an EventBridge rule. This rule defines a pattern to match incoming events. For our order event, the pattern might be:
{
"source": ["com.my-ecommerce-app.orders"],
"detail-type": ["New Order"]
}
This rule is then configured with targets. Targets are the services that will receive the event when the rule matches. You can have multiple targets for a single rule. For our order event, the targets could be:
- An SNS topic that fans out to email and SMS notification services.
- An SQS queue that feeds into the inventory service.
- A Lambda function that directly triggers the fulfillment service.
When the order event arrives at EventBridge, it’s evaluated against all your rules. If a rule’s pattern matches, EventBridge invokes the targets associated with that rule. This allows a single event to trigger multiple, decoupled actions.
The core problem EventBridge solves is decoupling event producers from event consumers. Instead of your order service needing to know about every single service that needs order information, it just publishes an event to EventBridge. EventBridge, acting as a central event bus, then figures out which services are interested and delivers the event to them. This makes your system more flexible, scalable, and easier to maintain. You can add new services that react to order events without modifying the order service itself.
SNS, on the other hand, is primarily for pub/sub messaging where a message is sent to a topic, and all subscribers to that topic receive a copy. It’s like a radio broadcast; once the signal is sent, everyone tuned in gets it. SNS is great for fan-out scenarios where you want to notify many different services or users simultaneously. For example, you might have an SNS topic for "new user registrations," and subscribers could include an email service, a welcome email service, and a marketing automation service.
SQS is a message queue service. It’s designed for decoupling and scaling microservices. When a producer sends a message to an SQS queue, it’s stored until a consumer comes along and reads it. Each message is typically processed by only one consumer. This is ideal for tasks that need to be processed reliably, one at a time, such as processing payment transactions, sending individual emails, or performing background jobs. If a consumer fails to process a message, it can be returned to the queue for another consumer to pick up.
Now, let’s talk about how these services can work together. It’s common to use EventBridge to route events to SQS queues. For example, an event arriving at EventBridge might match a rule, and that rule’s target could be an SQS queue. This allows EventBridge’s sophisticated routing and filtering capabilities to feed messages into a reliable, individual processing queue. You might also use EventBridge to trigger an SNS topic, which then fans out to multiple SQS queues, each for a different downstream service that needs to process the event independently.
A common misconception is that EventBridge replaces SNS and SQS. It doesn’t. Instead, it complements them. EventBridge acts as the intelligent router and filter for events, deciding what should happen based on the event’s content and metadata. SNS is excellent for broadcasting a single message to many interested parties simultaneously without complex filtering at the source. SQS is the workhorse for ensuring individual messages are processed reliably by a single consumer.
Here’s a key detail many overlook: EventBridge doesn’t store events indefinitely. If a target is unavailable or fails to process an event, EventBridge will retry based on its retry policy, but it won’t hold onto the event forever. For durable storage and guaranteed delivery when consumers might be offline for extended periods, SQS is the better choice. EventBridge can send an event to an SQS queue, and SQS will hold it until a consumer is ready.
The next step in mastering AWS messaging is understanding Dead-Letter Queues (DLQs) for SQS and how they help you manage messages that can’t be processed after multiple retries.