Event-Driven Lambda with SQS and SNS

Prerequisites: completion of Lambda Fundamentals; comfort with the AWS CLI and basic IAM policies.

Version note: verified against docs.aws.amazon.com/lambda (services-sqs, services-sqs-errorhandling, services-sqs-configure) and the SNS/Lambda integration docs, July 2026. ReportBatchItemFailures (partial batch response) has been GA for SQS event source mappings for several years and remains the current recommended pattern — there is no newer mechanism superseding it as of this writing. SQS "provisioned mode" pollers (dedicated, autoscaling pollers for high-throughput queues) are a comparatively recent addition worth knowing exists, but are out of scope for this introductory project.

Everything in Lambda Fundamentals was synchronous: you called invoke, and got a response back immediately. Plenty of real workloads don't fit that shape — a user uploads an order, and three different things need to happen (charge a card, update inventory, send a confirmation email) without the user's request waiting on all three, and without one slow downstream step blocking the others.

SQS (Simple Queue Service) and SNS (Simple Notification Service) solve this by decoupling producers from consumers. SQS is a durable queue: a message sits there until something explicitly processes and deletes it, which means a consumer that's down for five minutes doesn't lose any work. SNS is pub/sub: a single published message can fan out to many subscribers (including, commonly, multiple SQS queues) without the publisher knowing or caring who's listening. This project builds both patterns and, critically, the error-handling around them — because an asynchronous pipeline that silently loses or infinitely retries a bad message is worse than no pipeline at all.