Event-Driven Architecture with EventBridge & Step Functions

Tightly-coupled services fail together. Event-driven architecture decouples them: services emit events, other services react, and nobody needs to know who's listening. On AWS, the two workhorses are EventBridge (routing) and Step Functions (orchestration). Knowing which to use when is half the battle.

Choreography vs orchestration

This is the key distinction:

• Choreography (EventBridge): services emit events; consumers react independently. No central controller. Loosely coupled, scales well, but the overall flow is implicit, harder to see end to end.
• Orchestration (Step Functions): a central state machine explicitly drives a sequence of steps. The flow is visible and controllable, with built-in retries and error handling, but it's a single owner of the process.

Rule of thumb: EventBridge for "react to things happening," Step Functions for "run this multi-step process reliably." Most real systems use both.

EventBridge: the event router

EventBridge takes events and routes them to targets based on rules:

{
  "source": ["orders"],
  "detail-type": ["OrderPlaced"],
  "detail": { "total": [{ "numeric": [">", 100] }] }
}

• Event bus: the channel. Use a custom bus per domain, not the default.
• Rules: pattern-match events and route to targets (Lambda, SQS, Step Functions, etc.).
• Schema registry: documents your event shapes so producers/consumers agree.

Use it to fan out: one OrderPlaced event triggers inventory, email, and analytics independently, none of them knows about the others.

Step Functions: the orchestrator

When a process has ordered steps, branching, retries, and compensation, a state machine beats a tangle of Lambdas calling Lambdas:

Validate → Reserve Inventory → Charge Payment → Ship
                  │ (fail)            │ (fail)
                  └── release ◄───────┘  (compensation / saga)

• Built-in retry/catch per state: no hand-rolled retry loops.
• Visual execution history: you can see exactly where a run failed.
• Standard vs Express: Standard for long, auditable workflows; Express for high-volume, short-lived ones.

This is the natural home for the saga pattern (distributed transactions with compensation).

Putting them together

A common, clean shape:

EventBridge (OrderPlaced) ──▶ Step Functions (fulfilment workflow)
                          └──▶ Lambda (send confirmation email)
                          └──▶ SQS ──▶ analytics consumer

EventBridge decouples who reacts; Step Functions makes one reaction reliable and visible.

Patterns that keep it maintainable

• Version your events. Add fields, don't repurpose them. Consumers shouldn't break when you evolve.
• Use a DLQ everywhere. Failed events should land somewhere you can inspect and replay, not vanish.
• Make handlers idempotent. Events can be delivered more than once; process them safely twice.
• Don't over-orchestrate. If steps are truly independent, choreograph them. Reserve Step Functions for real sequential/transactional flows.

When NOT to go event-driven

• Simple request/response with no fan-out, a plain API call is clearer.
• When you need a strict, immediate, synchronous result, events are async by nature.
• Tiny systems where the indirection costs more than it saves.

Event-driven architecture is a tool for decoupling and resilience at scale, not a default. Used deliberately, EventBridge to route, Step Functions to orchestrate, it makes systems that bend instead of break.

---

Designing event-driven systems on AWS? That's exactly the kind of architecture I help teams get right, see my services or reach out.