Katkat
Back

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

Capital OneSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

A system design question that asks for the backend of a credit card system, then goes deep on what payment authorization latency is reasonable and how to achieve it, and on how to store cardholders' sensitive personal information. It tests transaction flow design, available-credit concurrency, latency budgeting, and data protection.

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.
  • In another version of this round, the interviewer opens with a written list of about five functional requirements instead of a one-line prompt. You are then expected to write the non-functional requirements yourself and agree on the scope of each listed requirement with the interviewer before you design anything.

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.

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?

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?

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

Hints

Hint 1

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 2

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.

Hint 3

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 4

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.

Hint 5

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 6

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.

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?