Event-Driven Order Processing Architecture on AWS
This design accepts an order through an authenticated API, publishes a durable domain event, and uses a saga to coordinate payment, inventory, fulfillment, and notification. It separates request latency from business processing while preserving explicit recovery paths.
Published August 18, 2026
Reference architecture
Architecture diagram
Open on the canvasEvent-driven order processing AWS architecture diagram with API Gateway, EventBridge, SQS, Step Functions saga, Lambda services, DynamoDB, and SNS. The image links to a fully editable BuildPlane starter.
Overview
An event-driven order pipeline where a checkout API emits events onto an EventBridge backbone. A durable SQS queue feeds an ingest worker, while a Step Functions saga fans out to adjacent payment, inventory, and fulfillment services with compensation. Order and inventory state live in DynamoDB and customers are notified via SNS.
Components
- Ingress: API Gateway with Cognito accepts authenticated orders and publishes an order-created event.
- Event Backbone: EventBridge routes events; SQS with a DLQ guarantees durable, retryable delivery.
- Orchestration: A Step Functions saga sequences payment and fulfillment with rollback on failure; the ingest worker persists state.
- Fulfillment: Dedicated Lambdas handle payment capture and stock reservation plus shipment creation.
- State: DynamoDB holds canonical order and inventory records; SNS fans notifications to customers.
Order Flow
- A customer submits an order; the checkout API authenticates and publishes it to EventBridge.
- EventBridge buffers the event on an SQS queue (with a DLQ) that drives the saga.
- The saga invokes the adjacent payment and fulfillment services.
- Payment records the order and fulfillment reserves inventory in DynamoDB.
- Fulfillment publishes status updates to customers through SNS.
Customize First
- Tune the saga steps and compensation for your payment, tax, and fraud requirements.
- Add idempotency keys and a redrive policy on the DLQ before production.
- Tap the event bus into Firehose/S3 for an analytics lake when you need BI and replay.
Design rationale
Decisions that shape this architecture
Publish acceptance before completing fulfillment
The checkout path records or emits an order-created fact and returns without waiting for every downstream service. Callers receive an order state, not a promise that fulfillment already finished.
Use routing and buffering for different jobs
EventBridge routes domain events to interested consumers. SQS protects the saga worker with buffering, delivery retries, and dead-letter handling.
Make compensation a first-class workflow
A saga must define what happens when payment succeeds but inventory or fulfillment fails. Step Functions makes those transitions and compensating actions inspectable.
Before production
Operational checks
Use idempotency keys at order intake and every retried side effect.
Define timeouts and compensation for payment, reservation, and fulfillment.
Track order state transitions with correlation IDs across services.
Own a DLQ redrive process that cannot duplicate completed business actions.
Scope and tradeoffs
What this diagram does not solve
Eventual consistency becomes user-visible
Order status may move through pending states while work completes. Product UX and support tooling need to explain and inspect those states.
Exactly-once business behavior is designed, not provided
Queues and functions can deliver or execute more than once. Durable idempotency and conditional state changes prevent duplicate charges and reservations.
Common questions
Frequently asked questions
Why use a saga for order processing?
A saga coordinates several local transactions and defines compensating actions when a later step fails, without requiring one distributed database transaction.
Why are EventBridge and SQS both shown?
EventBridge provides event routing and fan-out. SQS provides consumer buffering, backpressure, controlled retries, and a dead-letter queue.
Where should the canonical order status live?
The order store should record explicit, conditional state transitions. Events communicate changes, but they should not leave support teams without a queryable current state.
Keep exploring
Related AWS architectures
Serverless Multi-Tenant SaaS Architecture on AWS
This architecture combines a protected synchronous API with a durable asynchronous work path. Tenant identity travels from Cognito into application authorization, domain events decouple background work, and DynamoDB plus S3 provide scalable tenant state and assets.
Explore the architecture
Asynchronous File Processing Pipeline on AWS
This design accepts uploads immediately and lets workers process them at a controlled rate. S3 protects the source file, SQS absorbs bursts and retries, Lambda performs bounded work, and separate result and status stores make completion observable.
Explore the architecture
IoT Telemetry and Analytics Platform on AWS
This architecture authenticates a device fleet, buffers telemetry, preserves raw events, derives searchable and time-series views, raises operational alerts, and presents fleet trends. Each storage path serves a distinct access pattern instead of treating one database as universal.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.