Design a Credit Card System: Authorization, Fraud, Bureau Reports, Limit Increases

Design the back end of a credit card system for a card issuer. The system must support: 1. **Login.** Customers sign in to the issuer's website and mobile app. 2. **Payment authorization with a fraud check.** When a cardholder pays at a merchant, the card network sends an authorization request, and the system must approve or decline it in real time after checking for fraud. 3. **Monthly credit bureau reporting.** Every month, report each account to the credit bureaus. 4. **Spending overview.** Customers can see their spending: what they bought, where, when, and how much in total. 5. **Real-time credit limit increases.** A customer can request a higher credit limit and get a decision immediately. The system is large, and an interview slot does not leave time to design every part in depth. Lay out the core entities, the services and the main read and write paths first, then deep dive into one or two areas. It is reasonable to ask the interviewer which area they want to explore. ```hint Breadth first Before any deep dive, list the core entities and the services that own them, and trace one write path (a card swipe) and one read path (the spending overview) end to end. ``` ```hint Different clocks The five features run on very different time scales, from milliseconds to once a month. Let that decide which parts are synchronous and which run as batch or background work. ``` ### Constraints and Clarifications - No scale numbers are given. Ask for them, or state your own assumptions and size the design from them. - The card network connection and the bureaus' file formats are external interfaces; you do not design them. ### Clarifying Questions - How many cardholders, and what peak authorization rate, should the design handle? - What is the latency budget for an authorization decision, and what should happen if the fraud check cannot answer in time? - How fresh must the spending overview be, and does it include pending authorizations or only posted transactions? - For a credit limit increase, is the decision fully automated, and what data may it use: internal history only, or a new credit bureau inquiry? - Which area matters most to you for a deep dive? ### What a Strong Answer Covers - Entities, service boundaries and the main read and write paths laid out before any deep dive - An authorization path that is fast, idempotent and consistent with available credit, with a defined fallback when fraud scoring is slow or down - A ledger as the source of truth for balances, and derived read models for the spending overview - A batch pipeline for bureau reports that is complete, validated and re-runnable - A limit-increase flow with its data inputs, latency, audit trail and immediate effect on authorization - Security and compliance basics for card data and login, plus monitoring ### Follow-up Questions - How do you keep available credit correct when two authorizations on the same account arrive at the same moment? - An authorization was approved, but the network never sent the matching settlement. What happens to the hold? - A bug sent wrong balances to the bureaus last month. How do you detect it and send corrections? - How would you roll out a new fraud model without risking a spike in declined legitimate payments?