Case Studies
Stripe
Idempotency keys and an append-only ledger — making a charge exactly-once safe to retry, with money as the stakes.
Moving money between two parties exactly once, even though the network between the client and the service is unreliable — widely known in interview prep as "the Stripe problem," since Stripe's own public API docs are the most commonly cited real-world example of exactly this idempotency-key pattern. It's the sharpest possible illustration of idempotency, because here a duplicate side effect isn't a cosmetic bug, it's a double charge.
What this lesson covers
Every charge carries a client-generated idempotency key; the service stores the key and exact first result next to the ledger and replays it on retry. Record money movement as an append-only debit/credit ledger in one transaction, and publish downstream effects async.
- A charge request times out and the client cannot know if it succeeded; a naive retry charges the customer twice.
- Idempotency keys are the canonical fix, and this is the sharpest case for them because a duplicate side effect is a double charge.
- Keep an auditable, append-only record of every money movement instead of a balance that can silently drift from reality.
- Where the idempotency key itself lives is a real decision, not a given; a senior answer explains the choice.
- Staff answers handle a crash between committing the ledger and publishing the downstream event, e.g. with an outbox pattern.
Included in Plus and Pro
Continue reading “Stripe”
The full lesson works the design through end to end — diagrams, trade-offs, and what interviewers expect at each level. About 19 minutes.
- Understanding the Problem
- Functional Requirements
- Non-Functional Requirements
- Capacity Estimation
- Core Entities
- API Interface
- High-Level Design
- Trade-offs
- Final Design
- Operations & Observability
- Level Expectations
- Follow-Up Questions
- Try It Yourself