Lesson 15 of 30

EventBridge & Event-Driven Architecture

Q: A single OrderStatusChanged event needs to trigger customer notifications on refunds and a separate fraud-review flow for large amounts. How would you route that with EventBridge, and why not just use SNS?

A strong answer covers: Proposes publishing one event to an EventBridge bus and writing two independent rules with different event patterns (one matching status: refunded, one matching amount above a threshold); Explains that EventBridge routes based on the event's actual content, whereas SNS would deliver the full message to every subscriber regardless of content; Notes that adding a third reaction later means adding a third rule, without touching the publisher or the existing rules; Shows awareness that EventBridge often targets SQS or Lambda rather than replacing them.

SNS gives every subscriber the whole message. EventBridge asks a sharper question first: what's actually in this event, and who should even see it?

12 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

What's the core difference between how SNS and EventBridge decide who receives a given message?

SNS delivers to every subscriber on a topic; EventBridge routes based on rules that match the event's contentThey're functionally identical — EventBridge is just SNS with a different nameSNS is for scheduled events and EventBridge is only for real-time events

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on EventBridge & Event-Driven Architecture

What interviewers actually ask about this, and what a strong answer has to cover.

A single OrderStatusChanged event needs to trigger customer notifications on refunds and a separate fraud-review flow for large amounts. How would you route that with EventBridge, and why not just use SNS?

A strong answer covers

Proposes publishing one event to an EventBridge bus and writing two independent rules with different event patterns (one matching status: refunded, one matching amount above a threshold)
Explains that EventBridge routes based on the event's actual content, whereas SNS would deliver the full message to every subscriber regardless of content
Notes that adding a third reaction later means adding a third rule, without touching the publisher or the existing rules
Shows awareness that EventBridge often targets SQS or Lambda rather than replacing them

Likely follow-ups

You add the fraud-review rule, deploy it, and a week later notice it's never fired even though large refunds have happened. Nothing errored. How do you even find out something's wrong, and what's the likely root cause?
Why route through EventBridge to an SQS queue instead of just having the fraud-review rule target the review service's Lambda directly?

Practice these with the AI interviewer →

The plain-language idea

EventBridge is a central event bus: things publish events onto it, and rules decide who gets what based on the event's actual content, not a fixed subscriber list. A rule is an event pattern — a filter matched against the event's structure (its source, its type, fields inside its payload) — and only events matching that pattern get routed to that rule's targets.

This is the real difference from SNS. An SNS topic delivers the same message to every subscriber, full stop — filtering, if you want any, is a secondary bolt-on. EventBridge is built around the pattern match as the primary mechanism: one bus can carry many different kinds of events from many different sources, and each rule picks out only the slice it cares about. That makes EventBridge the better fit once "who should react to this" isn't just "everyone," but genuinely depends on what the event says.

See it in a real thing: one event, two rules, two destinations

{
  "source": "app.orders",
  "detail-type": "OrderStatusChanged",
  "detail": { "orderId": "o-482", "status": "refunded", "amount": 199 }
}

One event, two independent rules, two destinationsStep 1 of 4

One event lands on the bus: OrderStatusChanged, status=refunded, amount=199.

That single event lands on the bus once. One rule matches detail-type: "OrderStatusChanged" with detail.status: "refunded" and routes to a Lambda that triggers customer notifications. A second, independent rule matches any event where detail.amount exceeds a threshold and routes to a fraud-review queue — the same event, sliced two different ways, with neither rule aware the other exists. Adding a third reaction later means writing a third rule, not modifying the publisher or the other two rules at all.

What people usually miss

Watch out

EventBridge's filtering happens on the event's content, not just its type. A pattern can match on a nested field's actual value (like status: "refunded"), not only on "this came from the orders service" — that's what makes content-based routing possible instead of every subscriber getting everything and filtering client-side.
A rule with no matching events just does nothing — silently. There's no error when a rule's pattern never matches anything; a typo in a pattern (wrong field name, wrong nesting) produces a rule that looks configured but never fires, which is a real, easy-to-miss failure mode worth testing directly rather than assuming from the config.
EventBridge isn't a replacement for SQS or SNS — it's a routing layer that often points at them. A common real shape is EventBridge rule → SQS queue as the target, combining content-based routing with a queue's durability and independent consumption pace; picking one doesn't mean abandoning the other.
A scheduled rule still goes through the same rule-and-target model as an event-pattern rule. It's not a separate scheduling service bolted onto EventBridge — a cron expression is just another way a rule decides when to fire, using the same targets (Lambda, SQS, Step Functions, etc.) either kind of rule can point at.

Why this matters in interviews

"How would you route different downstream reactions off a single event without a growing pile of if/else in the publisher?" tests whether a candidate reaches for content-based routing (EventBridge rules matching on payload fields) instead of hardcoding every consumer's logic into whatever publishes the event.