How the interviewer opens it
“Design a service that approves or declines card transactions using available credit, card controls, and account status. It must handle holds, reversals, and duplicate requests within strict latency limits.”
The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.
What to clarify first
- Scale and traffic
- Account identifiers
- Latency
- Credit and controls
- Consistency
- Hold lifecycle
- Duplicates and message order
- Durability and retention
- Regions and failures
- Scope boundaries
The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.
Scope of a strong answer
Core requirements
- Approve or decline requests against account credit, card controls, and account status.
- Reserve credit with holds and release credit after reversals or expiry.
- Return the original decision for duplicate requests.
- Apply each full capture at most once.
Usually out of scope
- Card network protocols and card secrets
- Fraud models
- Payment collection, interest, and fees
- Disputes, refunds, and the full settlement process
What interviewers ask about
- Credit and account controls
- Several cards share credit, but each card also has separate controls. Every approval must obey both sets of limits.
- Repeated requests and lost responses
- A caller can lose the response after a valid approval. A repeat must recover that decision without a second hold.
- Changes to a hold
- Reversals, expiry, and captures change different parts of available credit. Late events must not release credit twice.
- Decision deadlines and failures
- The service must decide within 150 milliseconds. A fast response must not compromise the credit records.
Common mistakes
- Treats available credit as a value that each server can read and update independently.
- Uses a card lock even though several cards share one account.
- Treats a timeout as proof that the transaction failed.
- Saves duplicate results separately from the financial transaction.
- Requires an authorization record to find the account for an early reversal.
- Releases credit twice when a reversal, capture, or expiry repeats.
The bar by level
- Senior (L5/E5)
- Handles shared credit, daily controls, and freeze races. Defines account routing and identifier scope. Explains uncertain commits, early reversals, late captures, expiry races, and latency budgets.
- Staff (L6+/E6+)
- Defines partition boundaries and safe failover rules. Connects durability to response semantics. Plans audit retention, reconciliation, overload control, and high-volume account limits.