EventBridge and Event-Driven Architecture

Buses, rules, and targets; domain events vs commands; and the coupling concerns every subscriber has to handle

Bus → rule → up to 5 targetsmatched in parallel, not in sequence
Event: "X happened" · Command: "do X"broadcast with N listeners vs one intended handler
At-least-once deliverya handler must dedup by event id
Archive + replayscoped to one source bus, 10 concurrent replays per account/Region

1.Event buses, rules, targets, and patterns

An event bus receives events and routes them. A rule watches the bus for events matching an event pattern (or a schedule) and sends matches to one or more targets. An archive stores matched events so you can replay them later.

Key features

Every account has a default event bus (receives events from AWS services and PutEvents); you can also create custom buses and partner buses for SaaS integrations
A rule matches events either by an event pattern (JSON matched against the event's source/detail-type/detail fields) or by running on a schedule
A single rule can send to up to 5 targets by default, and they run in parallel, not in sequence
A failed target invocation retries per the rule's RetryPolicy (MaximumRetryAttempts: 0–185, MaximumEventAgeInSeconds: 60–86,400) — once retries are exhausted, the event goes to a dead-letter queue (a standard SQS queue) if one is configured
An archive is scoped to one source event bus (fixed at creation) and stores events matching an optional event pattern; replay can only send events back to that same source bus, and up to 10 replays can run concurrently per account per Region
Cross-account delivery: the receiving account's event bus grants a resource-based policy to the sender account (or an AWS Organization); the sender account then creates a rule targeting the receiver's event bus ARN

An event's path from source to target

PutEventsevaluatedagainstmatched → invoke(up to 5, parallel)matchingevents copied

Event source

Event bus

Rule (pattern or schedule)

Target(s)

Archive (optional)

Signature

bus → rule (pattern | schedule) → up to 5 targets, parallel

Bus routes, rule matches (pattern or schedule) and fans out to up to 5 parallel targets, archive stores a copy for replay back to the same source bus. Cross-account needs a resource policy on the receiving bus plus a rule on the sending side.

2.Domain events vs commands

A domain event says something already happened ("OrderPlaced") and the sender does not know or care who reacts. A command tells one specific receiver to do something ("ChargeCard") and expects it to happen.

Key features

Naming gives it away: events are past tense ("OrderPlaced", "PaymentFailed"); commands are imperative ("PlaceOrder", "ChargeCard")
An event has zero, one, or many subscribers, and the publisher never knows which — this is exactly what EventBridge's bus-and-rule model routes
A command has exactly one intended handler, and the caller usually needs a direct success/failure response — a fit for a direct API call or a targeted queue, not a fan-out bus
Publishing an event does not mean the action it describes will happen again — it means the action already happened; that's why events use past-tense verbs and commands use imperative ones
Mixing them up shows up as: an "event" bus doing point-to-point request/response, or a "command" being broadcast to receivers who shouldn't be able to reject it

Command

json

// Domain event — already happened, broadcast, no reply expected
{ "detail-type": "OrderPlaced", "detail": { "orderId": "o-123", "amount": 4200 } }

// Command — an instruction to one receiver, expects a direct outcome
{ "detail-type": "ChargeCard", "detail": { "customerId": "c-9", "amount": 4200 } }

Event = "this already happened," broadcast, any number of listeners. Command = "do this," one intended handler, an expected outcome. EventBridge's pattern-matched fan-out fits events; a direct call or targeted queue fits commands.

3.Designing loosely coupled event-driven services

Loosely coupled means a producer and its subscribers can change and deploy independently, because nothing depends on the other's internals. Event-driven systems buy that independence at the cost of four problems every subscriber has to handle: the event shape can change, the same event can arrive more than once, a failed delivery gets retried, and readers see stale data until the event catches up.

Key features

Versioning: add new fields as optional and keep old ones until every subscriber has migrated — a subscriber reading an unfamiliar field should ignore it, not fail
Duplicates: EventBridge Scheduler documents at-least-once delivery ("at least one delivery succeeds with a response from the target") — the same event can be delivered more than once, so a handler must be idempotent
Retries: a rule's RetryPolicy re-invokes a failing target automatically (bounded by MaximumRetryAttempts and MaximumEventAgeInSeconds); once exhausted, the event lands in a configured dead-letter queue instead of being silently dropped
Eventual consistency: a subscriber's local copy of another service's data is only as current as the last event it processed — there is a window where it is out of date, and the design has to tolerate that window
A common idempotency technique: track processed event IDs (EventBridge assigns each event a unique "id" field) and skip any ID already handled
Loose coupling is a trade: producers and subscribers deploy independently, but no subscriber can assume synchronous, in-order, exactly-once delivery — those guarantees have to be engineered per-handler, not assumed from the platform

Tightly coupled call vs loosely coupled event

Direct call (tightly coupled)

Caller knows the receiver and blocks for its response
A receiver's outage is the caller's outage too
Changing the receiver's contract requires coordinating both sides at once

Event via EventBridge (loosely coupled)

Producer publishes without knowing which — or how many — subscribers exist
A subscriber outage delays that subscriber only; retries and a DLQ absorb it
New subscribers can be added later with zero producer changes

Signature

versioning: additive fields · duplicates: dedup by event id · retries: RetryPolicy → DLQ · consistency: eventual, not immediate

Four things every subscriber has to handle, not the platform: the event shape changes (add fields additively, keep old ones until migration completes), delivery is at-least-once (dedup on the event ID), failed targets retry automatically then hit a DLQ, and a subscriber's copy of the world lags the source until its next processed event.

Spotted a mistake on this page? Tell us.

Read Sheet