Splitwise System – Low Level Design Interview Practice
Practise the Splitwise System low level design problem the way an LLD round actually runs. You are asked for requirements first, then a class model, and then to extend the design when a new requirement lands part way through – the follow-up that separates a design that was memorised from one that was understood.
The round checks the things interviewers grade: whether your classes carry single responsibilities, whether you reached for a design pattern or reinvented one, whether the design absorbs a new requirement without rewriting what exists, and whether you can explain a trade-off out loud. Feedback covers class modelling, SOLID principles, use of patterns, extensibility and communication.
What this question is really testing
Split algorithms and balance simplification. The data model is small; the interview is in how you represent who owes whom, and how you minimise the transfers.
Requirements to establish first
- Record an expense paid by one or more people on behalf of a group.
- Split equally, by exact amount, by percentage, or by share - and reject splits that do not sum to the total.
- Maintain a running balance between every pair of users.
- Show what one user owes and is owed, per group and overall.
- Settle up, and minimise the number of transfers needed to clear a group.
Core classes
- User – Identity. Balances are not stored here.
- Group – A set of users and the expenses recorded against them.
- Expense – Amount, payer(s), participants and the split used.
- Split – Abstract: EqualSplit, ExactSplit, PercentSplit, ShareSplit. Each validates its own totals.
- BalanceSheet – The pairwise net balances. The one structure every query reads.
- SettlementService – Reduces the balance graph to the fewest transfers.
Design patterns that apply
- Strategy – Split types, each with its own validation rule. Percentages must sum to 100; exact amounts must sum to the total.
- Observer – Recording an expense updates balances and notifies group members.
- Factory – Creating the right Split from the request type.
Follow-up questions to expect
- A owes B 10 and B owes C 10. Settle the group in one transfer rather than two - how?
- Rounding: three people split 100. Who absorbs the extra paisa, and is that decided in the split or the expense?
- An expense is edited after balances were derived from it. Do you recompute everything, or apply a delta?
Where candidates lose marks
- Storing balances per user rather than per pair, which cannot answer "what do I owe Rahul?".
- No validation that splits sum to the total, which lets money appear and vanish.
- Settlement as repeated pairwise netting without noticing it is a graph reduction.