Event-Driven Order Processing
An order-processing pipeline built with Lambda, DynamoDB, and SQS. Queues separate customer requests from background fulfillment.
At a glance
- 4 Lambda stages, none customer-blocking
- Orders over 10,000 get a separate worker
- DLQ split from business rejections
- Queue decouples intake from fulfilment
API Gateway · Lambda · DynamoDB Streams · SQS · EventBridge Pipes · CloudWatch
Architecture
Scroll the diagram horizontally to explore the full flow.
The problem
One synchronous request was responsible for validation, persistence, processing, retries, and monitoring. A slow worker therefore appeared to the customer as a slow checkout.
The decision
The customer-facing path records the order safely and responds. Everything after intake runs asynchronously from the DynamoDB stream and buffers in SQS, allowing order intake and fulfillment to scale independently.
An EventBridge Pipe filters high-value orders into a dedicated processing path without teaching the API about that routing rule. DynamoDB stores the current truth about an order; SQS stores work that remains outstanding.
Failure handling
Workers retry transient failures, rejected messages move to a dead-letter queue, and CloudWatch exposes queue age, error counts, and processing behavior.
What broke
A poisoned message reached the dead-letter queue exactly as configured, but the order remained in a processing state forever. Recovering the message had not recovered the business event.
The worker now writes a terminal failure state to DynamoDB before the message leaves the active queue. Infrastructure recovery and business-state recovery must be designed together.
Shape of the build
- API Gateway and Lambda intake
- DynamoDB state and streams
- SQS buffering and retries
- EventBridge Pipe filtering
- Dedicated high-value worker
- Dead-letter queue plus terminal order state