EvalcueAISystem design problem
Design a Payment System
Design a payment platform where correctness matters more than simply maximizing throughput. The interview focuses on idempotency, durable state transitions, money movement records, provider uncertainty, reconciliation, and safe retries.
Model the payment lifecycle explicitly
Clarify authorization, capture, refunds, payment methods, currencies, asynchronous provider results, and whether the system moves money itself or orchestrates payment processors. Represent payment state transitions explicitly instead of treating payment as one synchronous API call.
- Payment intent and attempt
- Authorize, capture, refund
- Explicit state machine
- Stable idempotency key
Keep a durable source of financial truth
Discuss immutable transaction records or a double-entry-style ledger where appropriate, atomic database updates, unique constraints, outbox patterns, and why cache should never become the authoritative record of money movement.
- Durable transaction records
- Atomic state transitions
- Ledger or accounting entries
- Transactional outbox for side effects
Design for ambiguous provider outcomes
Network timeouts can leave the caller unsure whether a provider completed a charge. Explain idempotent provider requests, webhook processing, polling when necessary, reconciliation jobs, duplicate-event handling, and operational tooling for exceptions.
- Idempotent retries
- Signed provider webhooks
- Reconciliation
- Audit trails and observability
Common questions
Why is idempotency critical in payment systems?
Clients and services retry after timeouts. Without idempotency, the same logical payment can be processed more than once. A stable key lets repeated requests return or continue the same operation safely.
Should Redis store payment state?
Redis can help with caching or coordination, but durable payment and ledger state should live in a transactional persistent store designed to preserve correctness across crashes and retries.
What is reconciliation?
Reconciliation compares your internal payment records with processor or bank records to find missing, duplicated, delayed, or inconsistent transactions and resolve discrepancies.