Connect SQS to Lambda, process an order and isolate a failing message in a dead-letter queue.
A shop needs to accept orders even when downstream processing is slow. You will decouple message submission from a worker and deliberately send a poison message to observe retries and failure isolation.
A valid order logged by Lambda and a failing order moved to a dead-letter queue after repeated processing attempts.
Order queueBuffers incoming orders
Order workerPolls queue through event source mapping
Execution logsSuccess and failure evidenceSource queue → dead-letter queue after repeated failuresSQS standard queues deliver at least once. Production workers need idempotent side effects, concurrency controls, alarms on queue age and dead-letter depth, and partial batch failure handling when using batches. This lab logs processing only; it does not charge a payment or persist an order.
A managed queue that buffers messages between producers and consumers.
Choose it when: Absorb traffic spikes and retry background work independently of the producer.
Consider the tradeoff: Use SNS for fan-out, EventBridge for event routing, or Kinesis for a replayable stream.
AWS service documentationRuns event-driven application code without managing servers.
Choose it when: Execute short, stateless tasks in response to events.
Consider the tradeoff: Use ECS or EC2 for long-running workers or specialized runtime requirements.
AWS service documentation
Policies and roles control which identities can perform actions on AWS resources.
Choose it when: Grant a workload only the actions and resources it needs using temporary role credentials.
Consider the tradeoff: Use IAM Identity Center for workforce sign-in; avoid embedding long-lived credentials in code.
AWS service documentationCollects logs and metrics to help you understand workload behavior.
Choose it when: Inspect application output, failures and operational signals.
Consider the tradeoff: Use CloudTrail to investigate AWS API activity; it serves a different purpose than application logs.
AWS service documentationSQS requests, Lambda execution and CloudWatch Logs may incur charges. Send two sample messages only, use a three-day log retention and delete the resources afterward.
Use a non-production account, sign in through an IAM role rather than root, and review AWS pricing. Budget alerts notify you; they do not automatically cap spending.
The source queue redrive policy points to the DLQ with maxReceiveCount 3.
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"],
"Resource": "SOURCE_QUEUE_ARN"
}]
}The execution role trusts lambda.amazonaws.com and has logging plus source-queue polling permissions.
import json
def lambda_handler(event, context):
for record in event["Records"]:
order = json.loads(record["body"])
if order.get("force_failure"):
raise ValueError("Intentional lab failure")
print(json.dumps({
"status": "processed",
"order_id": order["order_id"],
"message_id": record["messageId"]
}))
return {"ok": True}The SQS trigger is enabled with batch size 1.
If adding the trigger fails, confirm role permissions and that the queue and function are in the same region. Wait briefly for IAM propagation and retry.
{"order_id":"ORD-1001","force_failure":false}A log entry contains status processed and order_id ORD-1001. SQS eventually shows no visible/in-flight messages for this order.
{"order_id":"ORD-1002","force_failure":true}ORD-1002 appears in cloudadhar-orders-dlq, while ORD-1001 has a success log.
If the DLQ stays empty, verify the source redrive policy, enabled trigger and deployed code. Do not repeatedly poll the source queue; that changes receive counts.
No lab function, event source mapping, queue, log group or execution role remains.
Use these service guides and architecture frameworks to go deeper. The diagram above is an original teaching design, not an AWS-certified production blueprint.