Design coffee-shop card payments with tips and nightly batch settlement at scale

Design the payment system for coffee shops that take card payments at the counter. A customer's card is swiped for the purchase, the customer can add a tip, and each shop's transactions are submitted for settlement once per night. The interviewer's main focus is how the nightly settlement scales. Idempotency and reconciliation are expected parts of the discussion. Assume the usual card-present tip flow. The swipe obtains an authorization for the purchase amount, the tip is added afterwards as an adjustment, and the final amount (purchase plus tip) is captured when the day's transactions are submitted in the nightly batch. The card network and the payment processor are external systems you integrate with; you do not design them. ### Clarifying Questions - How many shops, terminals and transactions per day must the system handle, and in what nightly window must settlement finish? - Do all shops share one cutoff time, or does each shop close its day in its own time zone? - Until when can a tip be added or changed, and what happens to a tip entered after the shop's batch has been submitted? - Does the processor accept settlement as files, as batched API calls, or both? Does it accept an idempotency key or a batch reference? - Are payouts to the shops in scope, or only submitting and reconciling the settlement? ### Part 1 — Swipe and tip flow Design the data model and APIs for authorizing a swipe and adding a tip. Terminals retry requests when their connections are flaky. ```hint Retries are the default A terminal that times out sends the same request again. Decide what identifies "the same request", and what a tip change should mean if it is applied twice. ``` #### What This Part Should Cover - Transaction states from swipe to settlement, and the data each state needs - Idempotency for authorization and tip requests - Handling a processor timeout without placing two holds on the customer's card ### Part 2 — Nightly settlement at scale Every night, each shop's finalized transactions must be grouped and submitted to the processor. Design this so that it finishes within the nightly window as the number of shops and transactions grows, and so that a failure partway through the run neither loses nor duplicates transactions. ```hint Many small jobs Treat the nightly run as many small jobs rather than one big one, and decide how each job's progress survives a crash. ``` #### What This Part Should Cover - How the work is partitioned and scheduled, and how load is spread across the window - Exactly-once submission despite worker crashes and retries - Behavior when the processor is slow, throttles requests, or rejects part of a batch ### Part 3 — Reconciliation After submission, the processor reports what it settled. Design how you confirm that every transaction was settled for the right amount, and what happens when one was not. ```hint Match at the right grain Comparing daily totals tells you that something is wrong, not what is wrong. ``` #### What This Part Should Cover - Which records are compared, and at what grain - How mismatches are classified and resolved - Idempotent ingestion of the processor's reports ### What a Strong Answer Covers - A transaction state machine that every component respects - Money stored as integers in minor units, with an append-only audit trail - Estimates that actually drive the settlement design - Failure handling at each step: terminal retries, processor timeouts, worker crashes, partial batch rejections - Monitoring that shows whether tonight's settlement will finish on time and whether the books balance ### Follow-up Questions - How would the design change if transactions were settled continuously during the day instead of once per night, and what would that cost? - A shop says one night's deposit was short. Walk through how your system finds the cause. - How would you handle a refund issued the day after the original sale was settled?