Design an idempotent payment processing pipeline
Last updated: August 6, 2025
Quick Overview
Design a distributed payment processing system that guarantees exactly-once semantics for financial transactions, handles network failures, retries, and concurrent requests for the same payment.
Affirm
August 6, 20257
5
4,412 solved
Design a distributed payment processing system that guarantees exactly-once semantics for financial transactions, handles network failures, retries, and concurrent requests for the same payment.
Idempotency is foundational at Affirm. This question is asked to assess your deep understanding of exactly-once processing in distributed financial systems. Getting this wrong means consumers are double-charged, which is unacceptable.
What the Interviewer Expects
- Explain idempotency keys and their lifecycle clearly
- Design a system that handles crash-recovery scenarios without duplicate charges
- Address concurrent requests with the same idempotency key
- Discuss the interaction between idempotency and database transactions
- Consider how to handle idempotency across multiple microservices
Key Topics to Cover
How to Approach This
- Start by clarifying functional and non-functional requirements with the interviewer.
- Estimate the scale: QPS, storage, bandwidth. This drives your design decisions.
- Draw a high-level architecture first, then deep dive into 1-2 critical components.
- Discuss trade-offs explicitly (e.g., consistency vs availability, SQL vs NoSQL).
- Address failure scenarios, monitoring, and how the system handles 10x traffic spikes.
Possible Follow-up Questions
- How long should you store idempotency keys before expiring them?
- What happens if two requests with the same idempotency key arrive simultaneously?
- How does idempotency work when the payment involves multiple downstream services?
- How would you test that your system is truly idempotent?
Sharpen Your Skills on Codemia
Practice similar problems with our interactive workspace, get AI feedback, and track your progress.
Practice System Design ProblemsSample Answer
Requirements
Functional Requirements
- Idempotent Payment Processing: The system must ensure that repeated submissions of the same payment request (with the same idempotency key) result in exactly one tra...
Capacity Estimation
Assuming Affirm processes around 10 million transactions per day with peak traffic during sales events, we can break this down:
- Total Transactions: 10,000,000/day → 115 RPS (10,000,000/86400 sec...
Submit Your Answer
