How Stripe Uses Idempotency Keys to Prevent Double Charges

Episode notes

Stripe processes billions of dollars in payments every year. One double charge could destroy trust. In this episode, Lucas and Luna break down how Stripe uses idempotency keys - a simple but brilliant engineering pattern - to guarantee that even if a network request is retried dozens of times, the customer is charged exactly once. They walk through a real-world example: a customer hitting 'Place Order' twice during a card decline, the first attempt succeeds, and the second attempt should not create a duplicate charge. Lucas explains the idempotency key lifecycle: generation, storage in Redis, TTL, and response replay. He contrasts Stripe's approach with a naive dedup table and explains why idempotency is a design philosophy that ripples through error handling, database transactions, and API contracts. Luna pushes on edge cases: what if Redis goes down? What about race conditions between write and read? Lucas covers the safety nets - conditional writes, single-node Redis with replication, and the trade-off between performance and consistency. The episode closes with practical advice for any engineer building payment or booking systems: start with idempotency from day one.

• How Airbnb Rebuilt Search for 8 Million Listings42 / 100
• How GitLab Built a Single Codebase for One Million CI Pipelines45 / 100
• How Slack Rebuilt Its Search Index for 10 Million Daily Queries37 / 100
• How Notion Rebuilt Its Sync Engine for Offline-First
• How Notion Rebuilt Its Block Engine for Hybrid Local-Sync