---
title: "Building resilient webhook handlers in AWS: Implementing DLQs for Stripe events"
description: "Reliable Stripe webhook processing must account for lost deliveries from network or service outages, out-of-order events, and duplicates caused by Stripe retries. The proposed AWS architecture uses API Gateway for signature validation and throttling, an SQS FIFO queue for ordered delivery and content-based deduplication, Lambda for processing, DynamoDB for event-ID idempotency, and an SQS DLQ for failed messages. In the CloudFormation example, the main queue has a 300-second visibility timeout and sends messages to the FIFO DLQ after three receives; DynamoDB records expire through a seven-day TTL. Lambda retries failures with exponential backoff, while CloudWatch monitors queue depth, latency, and errors. The design is presented as a scalable foundation, with multi-region failover available at added cost and complexity, though single-region deployment may suffice for many applications."
---

# Building resilient webhook handlers in AWS: Implementing DLQs for Stripe events

[Stripe](https://yomu.fyi/company/stripe) · James Beswick · Jan 30, 2025

**Type:** Problem & solution

## Summary

Reliable Stripe webhook processing must account for lost deliveries from network or service outages, out-of-order events, and duplicates caused by Stripe retries. The proposed AWS architecture uses API Gateway for signature validation and throttling, an SQS FIFO queue for ordered delivery and content-based deduplication, Lambda for processing, DynamoDB for event-ID idempotency, and an SQS DLQ for failed messages. In the CloudFormation example, the main queue has a 300-second visibility timeout and sends messages to the FIFO DLQ after three receives; DynamoDB records expire through a seven-day TTL. Lambda retries failures with exponential backoff, while CloudWatch monitors queue depth, latency, and errors. The design is presented as a scalable foundation, with multi-region failover available at added cost and complexity, though single-region deployment may suffice for many applications.

## Context

Stripe webhook processing can encounter lost deliveries during network or service outages, out-of-order events, and duplicate deliveries caused by Stripe's retry mechanism. These conditions can create inconsistencies, race conditions, invalid state transitions, or double-processing in systems handling payment events.

## Approach / What changed

The architecture places API Gateway at the webhook entry point, forwards events to an SQS FIFO queue, and uses Lambda to process them with retry handling. DynamoDB stores processed event IDs with TTL-based cleanup for idempotency, while an SQS FIFO DLQ receives messages that fail after three receives. CloudWatch provides monitoring and alerting for queue and processing behavior.

## Takeaways

- The FIFO queue is configured with a 300-second visibility timeout, content-based deduplication, and a redrive policy that sends messages to the DLQ after three receives.
- The Lambda handler checks each Stripe event ID in DynamoDB before processing and records newly processed IDs with a TTL calculated for seven days.
- Multi-region failover adds redundant infrastructure, cross-region transfer, and DynamoDB Global Tables replication costs; the post says Stripe retries may make single-region deployment sufficient for many applications.

**Tags:** [AWS](https://yomu.fyi/topic/aws), [Monitoring](https://yomu.fyi/topic/monitoring), [Reliability](https://yomu.fyi/topic/reliability), [Scalability](https://yomu.fyi/topic/scalability), [Serverless](https://yomu.fyi/topic/serverless)

- Source: [Stripe](https://stripe.dev/blog/building-resilient-webhook-handlers-aws-dlqs-stripe-events)
- Source URL: https://stripe.dev/blog/building-resilient-webhook-handlers-aws-dlqs-stripe-events
- Ingested by Yomu: 2026-08-28T08:57:47.073Z

[Read original post](https://stripe.dev/blog/building-resilient-webhook-handlers-aws-dlqs-stripe-events)