Design Splitwise
What is Splitwise?
Splitwise is a popular expense-sharing application that helps groups of people such as roommates, friends, coworkers, or travelers split bills and keep track of who owes whom.
Loading simulation...
Rather than requiring users to settle up after every expense, Splitwise allows them to log payments as they happen. It maintains a running balance for each user, tracking how much they owe or are owed.
In this chapter, we will explore the low-level design of a splitwise like service in detail.
Lets start by clarifying the requirements:
1. Clarifying Requirements
Before starting the design, it's important to ask thoughtful questions to uncover hidden assumptions and better define the scope of the system.
Here is an example of how a discussion between the candidate and the interviewer might unfold:
Candidate: "Should the system support both one-to-one and group expenses?"
Interviewer: "Yes, we should support both. Users can create individual expenses as well as group expenses involving multiple participants."
Candidate: "Should the system support different ways of splitting an expense? For example, equal splits, exact amounts, and percentage-based splits?"
Interviewer: "Yes, we should support equal, exact and percentage-based splits."
Candidate: "How should we track balances? Should the system maintain who owes whom, or just a running total per user?"
Interviewer: "Maintain pairwise balances. If Alice owes Bob $50 and Bob owes Alice $20, the net balance should show Alice owes Bob $30."
Candidate: "Should users be able to settle up partially, or should settlements be allowed only in full?"
Interviewer: "Partial settlements should be supported. Users should be able to pay back in parts and see updated balances accordingly."
Candidate: "What happens with rounding in equal splits? For example, $100 split 3 ways is $33.33 each, but that only adds up to $99.99."
Interviewer: "Good question. The last person in the split should absorb the rounding difference. So two people pay $33.33 and the third pays $33.34."
Candidate: "Should we notify users when an expense is added or a settlement happens?"
Interviewer: "Yes, participants should be notified of new expenses and settlements."
Candidate: "Do we need to handle concurrent operations? For example, two expenses being added at the same time affecting the same users?"
Interviewer: "Yes, the system should be thread-safe. Balance updates should be consistent even under concurrent modifications."
Candidate: "Do we need to retain each expense after it is recorded, or only the final balances?"
Interviewer: "Each expense should be retained as an immutable record once it is added, and every expense and settlement should be reflected in the running balances between users."
Candidate: "Should we support multiple currencies or just assume a single currency for all transactions?"
Interviewer: "For now, let’s keep it simple and assume all transactions happen in a single currency."
Candidate: "Do we need to handle user input, or can we hardcode a sequence of operations?"
Interviewer: "You can hardcode the sequence for this design. No need for user input handling."
- Support adding users with basic profile information (name, email, phone)
- Support creating groups of users for shared expenses
- Support adding expenses with three split types: equal, exact amounts, and percentage-based
- Track pairwise net balances between users (who owes whom and how much)
- Support partial and full settlements between any two users
- Notify users when expenses are added or settlements occur
- Handle rounding differences in equal splits so the total always matches
- The design should follow object-oriented principles with clear separation of concerns
- The system should handle concurrent expense additions without race conditions
- The system should be modular and extensible to support new split types
- The components should be testable in isolation
After the requirements are clear, lets identify the core entities/objects we will have in our system.