How the interviewer opens it
“Design a service that records financial transactions and returns account balances. It must preserve correct balances when requests overlap, clients retry, or servers fail.”
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
- Ledger operations
- Accounts and deployment
- Traffic and read:write mix
- Balance and account rules
- Latency
- Consistency and availability
- Repeated requests
- Durability and history
- Identity and authorization
- Exclusions
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
- Record internal transfers with equal debit and credit totals.
- Return current balances and account history.
- Prevent repeated financial effects for the same request and prevent customer overdrafts.
- Record economic corrections as new balanced transfers.
Usually out of scope
- External payment systems
- Currency exchange
- Pending funds and credit products
- Active writes across multiple regions
- User identity services
- General accounting reports
What interviewers ask about
- Concurrent transfers and partial failures
- Separate transfers can spend the same balance. A server failure must never expose only part of a transfer.
- Repeated requests
- Retries must preserve successful and rejected results. Later changes to funds or account status must not change those results.
- Balance discrepancies and history
- A balance error can affect the derived value or the economic record. Each case requires a different correction.
- Busy accounts and service failures
- One shared account can serialize transfers. Failover must preserve financial effects and every terminal request result.
Common mistakes
- Using floating-point amounts or checking funds outside the transaction that changes the balance.
- Retaining successful request results but discarding terminal business rejections.
- Checking mutable business rules before returning a stored request result.
- Treating a timeout as failure or promising duplicate prevention across different request keys.
- Changing committed entries to correct an economic error.
- Adding database shards without defining how a transfer commits across accounts.
The bar by level
- Senior (L5/E5)
- Defines lock order, concurrent request behavior, and recovery from unknown commit results. Returns stored results before mutable business checks, subject to current authorization. Distinguishes derived balance repair from economic correction. Defines consistent history and safe failover.
- Staff (L6+/E6+)
- Quantifies shared-account contention and defines overload behavior. Proves failover preserves financial effects and terminal request results. Plans archive verification and seven-year request retention. Explains coordination costs and contract changes when transfers span databases.