## Scenario Design a payment platform that supports authorization, capture or charge, and later batch settlement with external payment providers. The authorization path is latency-sensitive and must not depend on an asynchronous queue before returning the provider's decision. Settlement is asynchronous and may exchange many bounded-size files rather than one enormous daily file. Cover idempotency, ledgering, provider integration, settlement cutoffs, file generation, partial provider responses, reconciliation, and recovery. ### Constraints & Assumptions - Clients, internal workers, and providers may retry requests or return an unknown outcome after a timeout. - Authorization and capture have different lifecycle states and may occur at different times. - Settlement volume is large enough that one file for a provider and day may be impractical. - Database rows can be sharded, and files live in durable object storage. - Monetary amounts use integer minor units and an explicit currency. - Acknowledged financial state must be auditable and reconstructable. ### Clarifying Questions to Ask - Is capture immediate, delayed, partial, or repeatable? - Which party is the ledger authority for each state transition? - What are provider cutoff, file-size, acknowledgment, and retry contracts? - Are settlement results synchronous, callback-based, or delivered as response files? - Which currencies, reversals, refunds, and dispute flows are in scope? ```hint Separate business identity from attempt identity One payment operation can have several network attempts, but retries must resolve to one durable authorization or capture result. ``` ```hint Make settlement chunks immutable Select a cutoff snapshot, assign records deterministically to bounded files, and persist each file manifest before transmission. ``` ### What a Strong Answer Covers - A synchronous authorization service with timeouts, provider routing, durable idempotency, and unknown-outcome recovery. - An immutable double-entry ledger plus explicit payment and provider-attempt state machines. - Capture, void, refund, and retry semantics that never duplicate money movement. - Deterministic cutoff selection and paginated file construction using stable ordering and manifests. - Idempotent file upload or submission, acknowledgments, partial failures, and resumable reconciliation. - Read scaling that does not weaken the settlement snapshot, plus sharding and bounded updates. - Security, tokenization, audit, metrics, and financial invariant checks. ### Follow-up Questions 1. What response should a client receive when the provider times out after possibly authorizing? 2. How do you resume file generation after a worker dies midway? 3. Why is updating every transaction row from one giant response risky? 4. How do late captures enter the correct settlement window? 5. What ledger entries represent a failed settlement followed by a retry?