Event-Driven Order Processing

A limited-edition tabletop miniatures preorder system called "The Miniforge." Orders arrive through API Gateway, persist in DynamoDB, trigger a Lambda via DynamoDB Streams, emit EventBridge events, and start Step Functions workflows that check inventory, reserve stock, process payment, and send notifications. The architecture exercises Simfra's event-driven capabilities across seven interconnected services.

Services

Service	Role
API Gateway V2	HTTP API accepting order submissions and status queries
Lambda	Four Python 3.12 functions: order-intake, stream-processor, inventory-checker, payment-processor
DynamoDB	Orders table (with streams) and inventory table, both SSE-KMS encrypted
DynamoDB Streams	NEW_AND_OLD_IMAGES stream on orders table triggering Lambda ESM
EventBridge	Routes OrderPlaced events to Step Functions via pattern-matched rules
Step Functions	Workflow with inventory check, reservation, payment, notification, and compensation
SQS	Notification queue and dead-letter queue for failed orders
SNS	Order notification topic with SQS subscription
KMS	Customer-managed key for DynamoDB, SQS, and SNS encryption
S3	Pipeline artifact storage
CodeCommit	Source repository for all Lambda functions
CodeBuild	Packages Python functions into zip archives
CodeDeploy	Lambda AllAtOnce deployment with alias shifting
CodePipeline	Orchestrates the full Source, Build, Deploy flow

Architecture

HTTP POST /orders --> API Gateway V2 --> order-intake Lambda
                                            |
                                         DynamoDB (orders table)
                                            |
                                         DynamoDB Streams (ESM)
                                            |
                                         stream-processor Lambda
                                            |
                                         EventBridge (OrderPlaced event)
                                            |
                                         EventBridge Rule
                                            |
                                         Step Functions Workflow
                                        /        |         \
                             inventory-checker  DynamoDB   payment-processor
                               (Lambda)       (UpdateItem)    (Lambda)
                                                    |
                                              SNS notification
                                                    |
                                              SQS queue
                                                    |
                                         On failure: DLQ

Orders progress through states: SUBMITTED, RESERVED, CONFIRMED, or FAILED. The Step Functions workflow implements a saga pattern - if payment fails after inventory reservation, a compensation step releases the reserved stock. Failed orders route to a dead-letter queue for manual review.

What This Validates

• DynamoDB Streams triggering Lambda via event source mapping with NEW_AND_OLD_IMAGES
• EventBridge pattern matching routing events to Step Functions targets
• Step Functions ASL execution with Choice states, parallel paths, and compensation logic
• Lambda invocation from Step Functions (inventory check, payment processing)
• DynamoDB direct integration from Step Functions (stock reservation via UpdateItem)
• SNS-to-SQS cross-service delivery with KMS encryption on both sides
• Dead-letter queue routing for failed processing
• Order lifecycle state machine: SUBMITTED, RESERVED, CONFIRMED, FAILED

Test Coverage

Tests validate CI/CD pipeline deployment with Lambda version publishing, smoke tests for all resources and connectivity, integration tests for the happy-path order flow (submit through confirmation via Step Functions) and failure paths (insufficient inventory, payment failure with compensation), security tests for KMS encryption across DynamoDB/SQS/SNS, and performance tests with 10 concurrent order submissions all reaching terminal status.