AWS Serverless Event-Driven Architecture

An order-style event pipeline: an API that accepts requests, a queue that absorbs bursts, idempotent consumers, fan-out through EventBridge, and dead-letter queues with alarms.

Problem

Synchronous APIs that call downstream systems directly fail when those systems are slow, and retries without idempotency create duplicates.

Solution

Accept and enqueue, then process asynchronously. Consumers record an idempotency key in DynamoDB with a conditional write, so retries are safe. Failures land in a DLQ with an alarm.

• API Gateway
• AWS Lambda
• Amazon SQS
• Amazon SNS
• EventBridge
• DynamoDB
• CloudWatch
• Terraform

• Clients must send an Idempotency-Key header; the order ID is derived from it, so a retried request gets the same order back.
• The processor claims each key with a DynamoDB conditional write (with TTL); a duplicate returns the stored result instead of reprocessing.
• SQS partial batch responses (ReportBatchItemFailures) so one bad message does not retry the whole batch; poison messages move to the DLQ.
• Correlation ID carried from the API through SQS message attributes into the EventBridge event detail, in structured JSON logs.
• Stdlib Python handlers with injected AWS adapters: 74 unit tests and an in-process demo run without an AWS account.
• Terraform module and example: HTTP API with throttling, Lambdas, SQS + DLQ, DynamoDB (on-demand, PITR), EventBridge bus and rule, SNS, alarms.

• One IAM role per function, granting only the actions it uses (the processor has no GetItem — duplicates are read from the failed conditional write).
• Request validation happens in the ingest function before anything is enqueued; malformed requests get a 400.
• SQS SSE, and SNS topics encrypted with a customer-managed KMS key whose policy lets EventBridge and CloudWatch publish.

• Eight alarms: DLQ depth, oldest message age, errors and throttles per function, failed EventBridge deliveries and API 5xx; DLQ redrive is documented.
• Reserved concurrency on the processor protects downstream systems; Terraform rejects a queue polling concurrency above it.
• Events can be delivered more than once by design — consumers deduplicate on the event ID.

• Pay-per-request suits spiky traffic: roughly $5.50 per million orders plus about $2.25/month fixed at approximate list prices (illustrative, see the project's cost doc).
• At sustained high volume, compare against containers.

No quantified results are published for this project. Figures from client work are confidential, and this portfolio only shows numbers that can be verified or reproduced.

• Idempotency is a design decision at the API contract, not something you bolt on in the consumer.
• Known gaps, stated in the README: no API authentication, WAF or tracing yet, and no read endpoint for order status.