Design a Credit Card System: Authorization Latency and Sensitive Data Storage

Design the backend of a credit card system. Cardholders have card accounts with credit limits and use their cards to pay merchants. Each purchase reaches the system as a payment authorization request that must be approved or declined, and approved purchases later become posted transactions on the cardholder's account. The system also stores the cardholders' personal information. The interviewer asked for an overall design first, then went deep on two areas: what payment authorization latency is reasonable and how to achieve it, and how to store users' sensitive personal information. ### Constraints and Clarifications - Assume you are designing the card issuer's side: the system that owns the cardholder accounts and credit limits and answers the authorization requests that card networks route to it. - Scale, regions and the full feature list are not given. Ask for them or state your assumptions. ### Clarifying Questions - Which features are in scope beyond authorization: statements and payments, rewards, disputes, card controls such as freezing a card? - How many cardholders and purchases per day, and what does the peak (for example, a holiday shopping day) look like? - Which personal data must be stored: card numbers, government identifiers, income, addresses, contact details? - Which regions and regulations apply? ### Part 1 — Core design Design the main components and the data model of the credit card system, and walk through what happens from the moment a purchase is attempted until it appears as a posted transaction on the cardholder's account. ```hint Approved is not yet posted A purchase is approved long before the money actually moves. Think about what the approval should change on the account immediately, and what changes later. ``` ```hint Two purchases at once The same account is charged twice within the same second, and together the two purchases exceed the available credit. Decide where the check happens so that both cannot be approved. ``` #### What This Part Should Cover - Components and a data model for customers, accounts, cards, authorizations and posted transactions - The authorization flow, and the later posting of approved purchases - Correct available-credit accounting under concurrent purchases and repeated messages - How statements, notifications and other downstream consumers receive transaction events ### Part 2 — Payment authorization latency What latency for a payment authorization do you consider reasonable, and how would you design the system to achieve it? ```hint Whose clock is ticking The cardholder is waiting at a checkout while the request passes through several parties before it reaches you. Decide how much of that wait your system may use. ``` ```hint Keep the critical path short List everything that must happen before you can answer approve or decline, and everything that could wait until after you have answered. ``` #### Clarifying Questions for this Part - Is the target for the issuer's own processing, or for the whole round trip the cardholder experiences at checkout? - Must fraud scoring finish before the decision, or may some checks run after it? #### What This Part Should Cover - A concrete latency target with a percentile, justified by where the issuer sits in the end-to-end checkout path - A critical path limited to the work the decision needs, with everything else moved off it - Fast access to account state and fraud signals, with timeouts and fallbacks when a dependency is slow - How the latency is measured and protected at peak load ### Part 3 — Storing sensitive personal information How would you store cardholders' sensitive personal information? ```hint Not all data is equally sensitive Sort the data you hold by sensitivity and by who actually needs to read it in clear form, before choosing protections. ``` ```hint Shrink what can leak Ask how many services truly need the real card number or identifier, and whether the others could work with a substitute value. ``` #### What This Part Should Cover - Classification of the data, including data that must not be kept at all - Encryption at rest and in transit, with key management and rotation - Reducing exposure: tokenization, masking, least-privilege access and audit logging - Lookups on protected fields, retention and deletion, and compliance obligations ### What a Strong Answer Covers - A coherent issuer-side design whose data model supports authorization, posting and statements - A defended authorization latency target and a critical path that meets it at peak - Correctness under concurrency, duplicate messages and partial failure, with no lost or double-counted money - Layered protection of sensitive data rather than a single "encrypt the database" step - What happens to authorization when a component fails or the system cannot answer in time ### Follow-up Questions - The fraud model's response time spikes at peak. How do you keep authorization within its latency target, and what do you give up? - An approval is recorded, but the response never reaches the card network. What happens to the hold on the account, and how is it reconciled? - How would you rotate the encryption keys that protect stored personal data without downtime? - A support agent must verify a caller's identity. What can the agent see, and how is that access controlled and audited?