Event-Driven Order Processing — Quick Learn

Checkout must tell a customer that an order was accepted only after that fact is durable. Payment, inventory, shipping, analytics, and email can then proceed independently without making the checkout request wait for every downstream system.

The design separates two moments:

Synchronous acceptance → asynchronous fulfillment and side effects

First Make Acceptance Durable

A common design writes the order and publishes OrderCreated as two separate actions. That creates a dual-write gap:

• Publish first, then fail to save the order → consumers see an order that does not exist.
• Save first, then crash before publishing → the order exists but downstream work never begins.

A transactional outbox closes that gap. The checkout transaction writes both the order and an outbox record describing the event. A relay publishes pending outbox records later.

Tap to exploreOpen diagram

The relay can publish an event and crash before marking the outbox record complete. It will publish again after restart. The outbox prevents a missing event; idempotent consumers make duplicate delivery safe.

Read deeper about durable acceptance and the transactional outbox

Route, Buffer, Coordinate, And Broadcast

These services solve different communication problems:

• EventBridge routes an event to matching targets based on its content. It decouples the producer from the systems interested in OrderCreated.
• SQS gives one consumer workload a durable backlog. Messages wait while workers are slow or unavailable, absorbing bursts and providing backpressure.
• Lambda performs the work when invoked or when it polls a queue.
• Step Functions coordinates an ordered business process with state, branches, retries, and compensation.
• SNS broadcasts one notification to many subscribers. Pair SNS with separate SQS queues when each subscriber needs both its own copy and a durable backlog.

One SQS queue with several unrelated consumers is not fanout: those consumers compete for messages. Use separate queues when shipping, analytics, and another worker must each process every order event.

Tap to exploreOpen diagram

The causal flow is:

1. Checkout commits the order and outbox record together.
2. The relay publishes OrderCreated to EventBridge.
3. EventBridge routes the fact to independent targets.
4. A Step Functions workflow coordinates payment, inventory, and shipping where order and state matter.
5. Separate SQS queues buffer independent consumers such as analytics.
6. SNS can broadcast customer or operational notifications when many subscribers need a copy.

Delivery Is At-Least-Once, So Processing Must Be Retry-Safe

When Lambda receives an SQS message, the visibility timeout temporarily hides it; it does not delete it. If the worker completes its external side effect and crashes before successful deletion, the message becomes visible again.

Therefore each consumer needs a stable event or operation ID and an atomic record of completed work. “Check, then act” without an atomic boundary can race. For batches, partial batch responses allow successful records to leave the queue while only failed records return.

A consumer queue DLQ holds messages that a consumer repeatedly could not process. An EventBridge target delivery DLQ records events EventBridge could not deliver to that target. They diagnose failures at different boundaries.

Monitor queue age, not only queue length. A growing age of the oldest message tells you that work is falling behind. Control consumer concurrency so catching up does not overwhelm a database or third-party dependency.

Read deeper about SQS retries, visibility, and idempotency

Workflows Need Explicit Failure Decisions

Step Functions is useful when fulfillment has ordered state: for example, authorize payment, reserve inventory, and request shipment. A failure may require a compensating action, such as releasing inventory after payment fails.

Compensation is a new business action, not time travel. It can also fail and must be observable and retry-safe. Do not use a workflow engine merely to replace one simple queue consumer.

Read deeper about ordered workflows and compensation

SAA Recognition And Traps

• Save a business record and reliably publish its event → transactional outbox, because two unrelated writes leave a crash gap.
• Route events by source, type, or content → EventBridge.
• Absorb bursts and let one workload process later → SQS.
• Coordinate ordered steps, branches, retries, and compensation → Step Functions.
• Send the same notification to many subscribers → SNS; add separate queues when each subscriber needs durable buffering.
• Duplicate deliveries are possible → idempotent consumers, because retries can occur after a side effect completed.

Do not mistake event acceptance for fulfillment completion, visibility timeout for deletion, a DLQ for automatic recovery, or one shared SQS queue for broadcast fanout.

One-Minute Review

Order + outbox commit together
↓
Relay publishes the durable fact
↓
EventBridge routes it
↓
SQS buffers independent work
Step Functions coordinates ordered work
SNS broadcasts notifications
↓
Idempotency makes redelivery safe; DLQs and queue age make failure visible

If you remember only one thing: accept the order durably first, then give routing, buffering, coordination, and broadcasting separate jobs.