The engineering problem
A client can lose the response after a server completes an operation. The client then cannot know whether retrying is necessary or dangerous. Stripe frames this ambiguity as a basic distributed-systems problem that appears even when only two systems communicate.
The approach
Idempotent operations let clients repeat a request without duplicating its effect. For mutating operations, an idempotency key gives the server a durable identity for the logical request. Stripe combines safe retries with exponential backoff and jitter so recovery does not amplify an outage.
Tradeoffs
The server must retain request identity and outcomes, define retention and conflict semantics, and decide how concurrent duplicates behave. Clients must reuse keys correctly and distinguish retryable failures from validation errors. Reliability is a shared protocol, not a header added at the end.
What generalizes
Forward-deployed teams often meet reliability at the integration boundary first. Stable identifiers, replay-safe commands, explicit status, reconciliation, and observable retries reduce adoption risk and support load while giving customer teams a predictable recovery model.
What is context-dependent
Not every operation can be made exactly repeatable, and external side effects may require sagas or reconciliation. Key retention, throughput, and consistency choices depend on business impact. Payment examples make duplication obviously serious; the same pattern also matters for provisioning, notifications, and workflow actions.
Architecture review questions
- What does the client know after a timeout?
- Which operations are replay-safe and how is identity represented?
- How are duplicate requests stored, expired, and observed?
- Will retries help recovery or create a thundering herd?
Stripe's article supplies the API pattern; the FDE and enterprise-integration implications are my synthesis.