Loading LLD design...
Design an object-oriented expense-sharing application (like Splitwise) that supports four split strategies — Equal, Exact, Percent, and Unequal (share-based) — group expense management, net balance tracking between every pair of users, settlement payments, and debt simplification to minimise transactions.
The core data structure is a balance sheet where balances[A][B] represents the net amount B owes A, with the invariant balances[A][B] == −balances[B][A]. Expenses are created by a single payer and split among participants using one of the four strategies. Settlements reduce outstanding balances. The simplify-debts algorithm reduces N×(N−1)/2 potential debts to at most N−1 transactions using a greedy approach.
Add users
Register users with name, email, phone
Create groups
Create groups with members for shared expenses
Add expense with equal split
One person pays, amount split equally among participants
Add expense with exact split
Each participant owes a specified exact amount
Add expense with percent split
Each participant owes a percentage of the total
Add expense with unequal (share-based) split
Split proportionally by shares (e.g. 2:3:5)
View balances
See who owes whom and how much — per user and per group
Record settlement payment
Record a payment from one user to another to reduce debt
Simplify debts
Minimise number of transactions within a group (greedy algorithm)
Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.
Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.
Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.
What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.
What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.