📨
Event-Driven Pipeline
SNS fan-out → SQS queues → Lambda processors → DynamoDB.
What you can build with this
Decouple parts of your application so they can scale and fail independently. Your application publishes events (order placed, user signed up, file uploaded) to SNS. Multiple SQS queues receive a copy and Lambda processes each queue independently. Results land in DynamoDB. Failed messages go to a dead-letter queue for inspection.
Deployment timing
After you run the deploy command, resources come online at different times. Check the validation steps in order.
| Resource | Ready in |
|---|---|
| SNS Topic | Ready at stack completion |
| SQS Queues | Ready at stack completion |
| SNS → SQS delivery | Near real-time (under 1 second typically) |
| SQS → Lambda trigger | Under 1 second from message arrival |
| Lambda cold start (first call) | 200ms–2s — subsequent calls are faster |
| DynamoDB write | Milliseconds from Lambda execution |
CloudFormation parameters
These are the values you will fill in when deploying the exported template. Changing these does not break the template — that is the point.
| Parameter | What to provide | Example |
|---|---|---|
| TopicName | SNS topic name — your app publishes events here | app-events |
| QueueName | Primary SQS processor queue name | event-processor |
| TableName | DynamoDB table for processed results | processed-events |
| LambdaS3Bucket | S3 bucket with your processor zip | my-artifacts |