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 we support multiple amount split strategies (example: equal split, exact amount etc..)?
Interviewer: At a minimum, we should support equal, exact and percentage-based splits.
Candidate: Should the system simplify debts by offsetting mutual balances or minimizing transactions across the group?
Interviewer: Yes, we should implement a debt simplification feature that helps reduce the number of transactions required to settle up.
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: Do we need to maintain a complete history of all expenses and settlements?
Interviewer: Yes, the system should keep a record of all expenses and payment activities so users can view their transaction history.
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.
1.1 Functional Requirements
- Support creation of both one-to-one and group expenses
- Allow expenses to be split using different methods, such as equal split and exact amount
- Track how much each user owes and is owed, across individuals and groups
- Maintain a history of all expenses, payments, and settlements
- Support partial settlements and update balances accordingly
- Allow users to view outstanding balances per user and per group
- Implement a debt simplification feature to minimize the number of transactions required to settle up
1.2 Non-Functional Requirements
- Modularity: The design should be modular and follow object-oriented principles for easy maintenance and extension
- Consistency: Expense updates and settlements should reflect accurately and immediately in the balance calculations
- Extensibility: The system should be flexible enough to support additional split types (e.g., percentage-based) and multiple currencies
- Thread-Safety: Multiple users might add expenses concurrently. Balance updates should be thread-safe to avoid race conditions.
After the requirements are clear, lets identify the core entities/objects we will have in our system.