How the interviewer opens it
“Design a digital wallet with stored balances and transfers between users. Prevent double spending during concurrent requests and partial failures. Prevent duplicate transfers when clients retry with the same sender and request key.”
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
- Wallet rules
- Identity and initial funds
- Scale
- Read and write mix
- Latency
- Consistency and availability
- Durability and retention
- Repeated requests
- Transfer history
- Regions and failure responses
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
- Create one wallet for an authenticated user.
- Read a wallet balance and its transfer history.
- Transfer funds between wallets without an overdraft.
- Return the original result for retries with the same sender and request key.
Usually out of scope
- Bank and card integration
- Currency exchange, fees, interest, and credit
- Identity verification and compliance systems
- Writes from multiple regions at the same time
What interviewers ask about
- Concurrent transfers
- Several requests can spend the same balance. Each transfer must change both wallets and their history as one action.
- Repeated transfer requests
- A repeated request can mean a retry or a new payment. The service needs a stable identity for each intended transfer.
- Transfers during failures
- A timeout does not reveal whether a transfer committed. Recovery must preserve acknowledged transfers and prevent conflicting balance changes.
Common mistakes
- Checking a balance before a separate debit without concurrency control.
- Changing the two wallet balances in separate transactions.
- Allowing concurrent creation requests to create multiple customer wallets for one owner.
- Keeping duplicate request records only in a cache.
- Treating a timeout as a definitive transfer failure.
- Restoring balances without their ledger entries and request results.
The bar by level
- Senior (L5/E5)
- Specifies concurrency control, ledger invariants, unique wallet ownership, and atomic request results. Explains deadlock or serialization retries, uncertain commits, and safe database failover. Justifies one database at the stated scale.
- Staff (L6+/E6+)
- Defines the failure contract across replicas, clients, and recovery. Preserves duplicate checks through archival and restore. Explains cross-database transfers and hot-wallet limits without weakening money guarantees.