Design Splitwise (Equal, Exact & Percent Splits + Simplify Debt)
In a 45-minute LLD interview, the interviewer evaluates financial domain precision, strategy isolation, and debt simplification. Scope the design to: registering users, recording expenses across three split algorithms (Equal, Exact, Percent), storing all monetary balances strictly in integer paise (int64_t) to prevent floating-point drift, and computing simplified settlement transactions using a greedy min-cash-flow algorithm. Group hierarchies and multi-currency exchange can be deferred to follow-up questions.
Problem statement & clarifying requirements
Design Splitwise, an expense-sharing application where friends and roommates track shared bills. The system must support Equal, Exact, and Percentage splits, rigorously validate that individual shares sum to the total bill, maintain running net balances across users, and compute simplified debt settlements to minimize the number of cash transfers needed to settle all accounts.
All internal monetary amounts are stored as 64-bit integer paise (int64_t). No floating-point types are used for account balances or ledger transactions.
The remainder paise (total % n) are distributed one-by-one to the first r participants so that the sum of parts strictly equals the total.
Exact splits must sum exactly to the bill total. Percentage splits must sum to 100.0% within a tiny epsilon (1e-4), and the final participant absorbs rounding differences.
A greedy min cash-flow algorithm pairs the largest debtor with the largest creditor, transferring min(|debt|, credit) until all net balances are cleared.
First, sketch the design yourself
Spend 5 minutes listing the classes, who owns whom, and which interface hides the part that changes.
- 1.
Strategy Pattern for split logic: Splitting algorithms (
Equal,Exact,Percent) share a common goal but have distinct validation requirements and inputs. Isolating them behindSplitStrategypreserves the Open-Closed Principle (a1). - 2.
Zero-sum financial accounting invariant: Across all registered users, the sum of all net balances must always equal zero. If a dollar is credited to a payer, exactly that dollar must be debited across participants.
- 3.
Decoupling expenses from settlement: Do not store directed edges between every pair of users for each bill. Track each user's single scalar net balance, then calculate settlement transactions on demand.
How to think through this problem (5-step walkthrough)
In a 45-minute LLD interview, the interviewer evaluates financial domain precision, strategy isolation, and debt simplification. Scope the design to: registering users, recording expenses across three split algorithms (Equal, Exact, Percent), storing all monetary balances strictly in integer paise (int64_t) to prevent floating-point drift, and computing simplified settlement transactions using a greedy min-cash-flow algorithm. Group hierarchies and multi-currency exchange can be deferred to follow-up questions.
Not every noun in the prompt deserves its own class. Separate dumb data structs from stateful managers, and turn trivial nouns into fields or enums.
UserValue struct representing an account holder with unique ID, display name, and contact information.
SplitValue struct binding a user ID to their allocated debt amount in integer paise (int64_t).
SplitStrategyStrategy interface declaring calculateSplits(totalPaise, participants, values) to calculate individual user shares and validate split mathematical constraints.
SplitFactoryFactory Method encapsulating strategy instantiation based on SplitType enum (EqualSplitStrategy, ExactSplitStrategy, PercentSplitStrategy), decoupling client callers from concrete calculation classes.
SplitwiseServiceCentral ledger context managing registered users, recording expenses, updating net balance counters, and running greedy debt simplification.
CurrencySymbol / PercentageValueTrap noun — do not create separate classes for currency symbols or percentages; currency formatting belongs in UI/presentation layers, and percentages are simple input values validated directly within PercentSplitStrategy.
A naive implementation stores pairwise directed debts for every single bill (e.g. debts[alice][bob] += 50, debts[bob][alice] += 20). With dozens of shared meals and cab rides, a dense web of redundant reciprocal debts forms, making settlement messy and prone to cycles. Even worse, using double or float for money leads to floating-point representation drift (e.g. 0.333333 * 3 != 1.00), causing balance sheets to lose cents over time.
A massive if-else or switch block in addExpense violates the Open-Closed Principle; adding a new split model (like shares or adjustments) risks breaking existing financial validation.
Hardcoding pairwise bilateral settlements forces users to make unnecessary circular payments instead of settling net balances globally.
- ✓
Zero-sum financial accounting: Across all users in the system, the sum of all net balances must always equal zero ($\sum netBalance = 0$). Every rupee credited to the payer is precisely matched by rupees debited from the participants.
- ✓
Integer arithmetic preservation: All financial operations use 64-bit integers representing paise (
int64_t). For odd amounts in equal splits, remainder paise (totalPaise % n) are distributed one-by-one to early participants so no fractions are dropped. - ✓
Bounded settlement transactions: Greedy debt simplification processes N non-zero account holders in at most N-1 bilateral cash transfers by iteratively matching the largest debtor with the largest creditor.
Entities & design patterns used
Unlock Full UML Diagram & C++23 Solution
The complete UML diagram, production-ready C++23 code, follow-up extensions, and design pitfall analysis are part of Brute2Best Pro. All 7 foundation chapters are 100% free.
First anchor question per pattern, Part 1 LLD & Module 1 C++ basics are 100% Free forever.