---
title: "Load balancing Stripe API calls from multiple AWS regions"
description: "The guide describes a multi-region payment-processing architecture for applications that use Stripe’s API and need resilience against regional outages, latency, rate limits, and payment-data compliance constraints. It routes requests with Amazon Route 53 health checks and configurable latency-based, weighted, or geolocation policies, while identical regional API Gateway and Lambda deployments process payments. DynamoDB Global Tables replicate payment state and support distributed rate limiting, with optimistic locking, regional token-bucket allocation, retries, and exponential backoff for Stripe requests. The sample Lambda records a payment as PENDING, creates and confirms a Stripe PaymentIntent, then updates the state with the Stripe payment ID and returned status; the conclusion presents the design as a foundation for regional resilience, state consistency, and API-rate management."
---

# Load balancing Stripe API calls from multiple AWS regions

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

**Type:** Tutorial

## Summary

The guide describes a multi-region payment-processing architecture for applications that use Stripe’s API and need resilience against regional outages, latency, rate limits, and payment-data compliance constraints. It routes requests with Amazon Route 53 health checks and configurable latency-based, weighted, or geolocation policies, while identical regional API Gateway and Lambda deployments process payments. DynamoDB Global Tables replicate payment state and support distributed rate limiting, with optimistic locking, regional token-bucket allocation, retries, and exponential backoff for Stripe requests. The sample Lambda records a payment as PENDING, creates and confirms a Stripe PaymentIntent, then updates the state with the Stripe payment ID and returned status; the conclusion presents the design as a foundation for regional resilience, state consistency, and API-rate management.

## Context

Global payment systems can be affected by regional API outages, network latency, Stripe API rate limits, and requirements such as GDPR and PSD2 data handling and customer authentication. A single-region design can cause service disruption, lost transactions, and high latency for customers in distant regions.

## Approach / What changed

Deploy identical payment-processing infrastructure in multiple AWS regions. Use Route 53 for DNS routing, health checks, and failover; API Gateway and Lambda for regional request handling; DynamoDB Global Tables for replicated payment state and rate-limit coordination; and Stripe’s API for payment intents. The rate-limiting design uses regional token buckets, optimistic locking, retries, and exponential backoff.

## Takeaways

- Route 53 health checks monitor regional payment endpoints and can support latency-based, weighted, or geolocation routing with DNS failover.
- DynamoDB Global Tables replicate payment state across regions, while optimistic locking and conditional writes are used to handle rate-limit update races.
- Stripe requests use token acquisition, up to three retries, exponential backoff capped at 30 seconds, and special handling for rate\_limit\_exceeded errors.

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

- Source: [Stripe](https://stripe.dev/blog/load-balancing-stripe-api-calls-multiple-aws-regions)
- Source URL: https://stripe.dev/blog/load-balancing-stripe-api-calls-multiple-aws-regions
- Ingested by Yomu: 2026-08-28T08:58:10.278Z

[Read original post](https://stripe.dev/blog/load-balancing-stripe-api-calls-multiple-aws-regions)