Katkat
Back

Design a Buy-Now-Pay-Later Checkout Backend: Latency and PII Storage

Capital OneSoftware Engineer · Technical Screen
MediumSoftware EngineerTechnical ScreenSystem Design

Last updated

Design the backend of a buy-now-pay-later checkout financing service that approves or declines a purchase in real time against a shopper's revolving credit line, then go deep on latency budgeting for the decision and on securely storing borrowers' personal data.

Design the backend for a buy-now-pay-later (BNPL) service. Shoppers are pre-approved for a revolving credit line; at checkout on a partner merchant's site, the shopper chooses to split a purchase into installments, the backend must approve or decline that purchase in real time, and an approved purchase becomes an installment plan that later generates scheduled charges against the shopper's linked payment method. The system also holds the shopper's personal and financial information needed to underwrite and service that credit line.

The interviewer wants a first pass at the overall design, then goes deep on two things: what checkout decision latency is achievable and how, and how shoppers' sensitive personal data is stored.

Clarify first

  • What's in scope beyond the approve/decline decision: installment scheduling, late fees, merchant settlement, dispute handling?
  • Rough scale: purchases per day, and what a peak shopping event looks like?
  • Which personal data must be stored: government ID numbers, income, bank account/card numbers, contact details?
  • Which regions and lending regulations apply, and does that change what must be stored where?

Part 1 — Core design

Design the main components and data model, and trace what happens from the shopper clicking "Pay in 4" at checkout to the first installment later being charged. Be explicit about what changes on the shopper's account the instant a purchase is approved, versus what only changes later when installments are actually collected.

Part 2 — Checkout decision latency

Merchants expect an approve/decline response in well under a second so checkout doesn't stall. Identify what the decision path actually has to do synchronously, what can move out of the hot path, and how you'd defend a specific latency budget (for example, p99 under 400ms).

Part 3 — Two shoppers, one credit line, at the same instant

The same shopper opens two tabs and completes two separate purchases within the same second, and together they exceed the shopper's available credit line. Walk through exactly what prevents both from being approved.

Part 4 — Storing sensitive shopper data

Design the storage for shoppers' personal and financial data such that compromising any single service doesn't expose it in usable form, while the underwriting and servicing flows that legitimately need it still work without excessive latency.

Hints

Hint 1

Separate 'available credit line' (decremented synchronously at approval, the concurrency-sensitive number) from 'amount actually collected' (updated later by the installment-billing flow) — they are different numbers with different update timing.

Hint 2

For the two-tabs race, think about what a single conditional update against the credit line does to the second request versus adding an application-level lock or distributed lock service.

Hint 3

For latency, separate what must happen before responding to the merchant (credit line check, a fast risk score, writing the approval) from what can happen asynchronously after (notifications, full underwriting refresh, analytics events).

Hint 4

For PII, think in layers: a vault service that's the only thing holding raw sensitive values, tokens or references used everywhere else, and encryption keyed so that a breach of one downstream service only exposes tokens, not raw data.

Follow-up questions

  • How would you redesign the credit-line check if purchases can come from multiple regions, each with its own database, for the same shopper?
  • A merchant disputes a charge three weeks after an installment was already collected. Walk through what data and which services are involved in resolving it.
  • How would you detect and rate-limit a bot that's rapidly probing checkout approval for stolen card numbers, without adding latency to legitimate shoppers?
  • If regulators require shoppers to be able to request full deletion of their personal data, how does the vault design above support that without breaking historical loan records that must legally be retained?