---
title: "Optimizing Stripe API performance in Lambda with caching strategies"
description: "The post addresses performance, cost, latency, and rate-limiting challenges that arise when applications make high-volume requests to Stripe's API from AWS Lambda. It presents a two-level cache using ElastiCache for Redis as the first layer and DynamoDB as the durable second layer, with Lambda coordinating cache reads, Stripe retrieval, and writes. On a miss, the function checks Redis, then DynamoDB, fetches the customer from Stripe if necessary, and stores the response in both layers with one-hour Redis and 24-hour DynamoDB TTLs. The DynamoDB design uses composite keys, a GSI for cache-type and timestamp queries, TTL cleanup, and environment-specific capacity settings; the post also discusses Redis connection pooling, Lambda sizing, capacity planning, cost control, monitoring, and webhook-based invalidation."
---

# Optimizing Stripe API performance in Lambda with caching strategies

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

**Type:** Problem & solution

## Summary

The post addresses performance, cost, latency, and rate-limiting challenges that arise when applications make high-volume requests to Stripe's API from AWS Lambda. It presents a two-level cache using ElastiCache for Redis as the first layer and DynamoDB as the durable second layer, with Lambda coordinating cache reads, Stripe retrieval, and writes. On a miss, the function checks Redis, then DynamoDB, fetches the customer from Stripe if necessary, and stores the response in both layers with one-hour Redis and 24-hour DynamoDB TTLs. The DynamoDB design uses composite keys, a GSI for cache-type and timestamp queries, TTL cleanup, and environment-specific capacity settings; the post also discusses Redis connection pooling, Lambda sizing, capacity planning, cost control, monitoring, and webhook-based invalidation.

## Context

High-volume interactions with Stripe's API can encounter rate limits and 429 errors, API latency typically ranging from 100ms to 500ms, and increased AWS infrastructure costs from unnecessary calls.

## Approach / What changed

Use AWS Lambda to coordinate a multi-layer cache: check ElastiCache for Redis first, then DynamoDB, and finally Stripe on a cache miss. Store newly fetched data in both layers, using Redis for fast access and DynamoDB for durable storage, TTL management, flexible key designs, and cache maintenance queries.

## Takeaways

- Redis is checked before DynamoDB, while Stripe is called only when the requested data is absent from both cache layers.
- The example assigns cached data a one-hour Redis expiry and a 24-hour DynamoDB TTL, with DynamoDB configured for automatic expired-item cleanup.
- The design uses DynamoDB composite keys and a GSI to support multiple item types, stale-entry queries, and bulk cache invalidation.

**Tags:** [AWS](https://yomu.fyi/topic/aws), [Caching](https://yomu.fyi/topic/caching), [Performance](https://yomu.fyi/topic/performance), [Redis](https://yomu.fyi/topic/redis), [Serverless](https://yomu.fyi/topic/serverless)

- Source: [Stripe](https://stripe.dev/blog/optimizing-stripe-api-performance-lambda-caching-elasticache-dynamodb)
- Source URL: https://stripe.dev/blog/optimizing-stripe-api-performance-lambda-caching-elasticache-dynamodb
- Ingested by Yomu: 2026-08-28T08:58:33.381Z

[Read original post](https://stripe.dev/blog/optimizing-stripe-api-performance-lambda-caching-elasticache-dynamodb)