How the interviewer opens it
“Design a service that tracks shared expenses and balances within groups. Members can edit expenses, record payments to each other, and see simpler ways to settle their debts.”
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
- Users and groups
- Traffic and data size
- Expense rules
- Edits and settlements
- Currency
- Transfer suggestions
- Latency
- Consistency and availability
- Retries and durability
- Existing systems and 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 expenses with one payer and equal or exact shares
- Keep balances correct after expense edits or deletion
- Show group balances and suggest simpler transfers
- Record settlements and preserve financial history
Usually out of scope
- Actual money transfers
- Currency conversion
- Multiple payers for one expense
- User identity and group membership management
What interviewers ask about
- Expense changes after a settlement
- An expense edit changes what members owe. It must not erase money that members already transferred.
- Repeated and simultaneous requests
- Concurrent edits can replace another member's change. Retries can record the same payment twice while all balances still sum to zero.
- Who should pay whom
- Simpler transfers can change the recipient without changing anyone's net balance. A later settlement can make an earlier suggestion obsolete.
- Amounts and shares
- Equal shares can leave a remainder. Expense edits must not create or remove the smallest currency unit.
Common mistakes
- Use floating-point amounts or ignore share remainders.
- Recalculate balances from expenses without prior settlements.
- Replace current balances with a simplified transfer list.
- Update expenses, history, and balances through separate commits.
- Treat retries as new settlements.
- Require the exact minimum transfer count before the basic service works.
The bar by level
- Senior (L5/E5)
- Defines durable idempotency and revision conflicts. Explains concurrent edits, settlement corrections, and balance recovery. Produces valid transfer suggestions from a consistent snapshot.
- Staff (L6+/E6+)
- Defines group ownership and safe failover without losing acknowledged changes. Handles stale suggestions after real transfers. Explains audit repair, growth limits, and when group serialization becomes insufficient.