Design a payment system that handles about 10,000 transaction requests per second. Each transaction first goes to an external payment service for approval or denial. An approved transaction places a hold for the amount. Once per day, approved transactions are grouped for final processing or settlement. Discuss APIs, state transitions, storage, idempotency, ledgering, external-provider failures, and reconciliation. ### Constraints & Assumptions - Duplicate client requests and duplicate provider callbacks are expected. - Money movement must be auditable; balances cannot be reconstructed only from mutable status fields. - A daily batch may be retried without settling a transaction twice. ### Clarifying Questions to Ask - What does the hold reserve and when does it expire? - Can a transaction be captured, canceled, or partially settled before the daily batch? - Is one external provider used or several? ```hint Separate workflow state from accounting facts A transaction state machine coordinates work; an append-only double-entry ledger records financial effects. ``` ### What a Strong Answer Covers - Idempotent request and callback handling, an explicit transaction state machine, and provider timeouts. - Holds, immutable ledger entries, daily batch membership, settlement, and safe retries. - Partitioning, outbox or inbox patterns, reconciliation, observability, and operational repair. ### Follow-up Questions - What if approval succeeds but the response is lost? - How would you close a settlement batch while new approvals continue? - How would a chargeback appear in the ledger?