Getting Ready: Splitwise

Splitting expenses among friends seems trivial — until you realize that Splitwise processes millions of expense records daily across 100+ million users worldwide. What starts as "divide by N" quickly turns into a complex system when you introduce percentage-based splits, exact-amount splits, multi-currency support, group expenses, and the fundamental challenge: minimizing the number of actual money transfers needed to settle all debts.

The core engineering challenge is debt simplification. Imagine five friends on a trip where dozens of expenses are shared unevenly. Without simplification, settling requires one payment per debt relationship — potentially O(N²) transfers. Splitwise's algorithm reduces this to at most N-1 transfers by computing net balances and matching creditors with debtors optimally. This is a graph problem at its heart, and companies like Splitwise, Tricount, and Settle Up all implement variants of it.

As an LLD interview problem, Splitwise is a Medium-difficulty favorite that tests multiple design patterns working together. Interviewers expect you to model different split strategies (equal, exact, percentage) using the Strategy Pattern, handle balance change notifications with Observer, support expense undo via Command, and — critically — demonstrate the debt simplification algorithm. Unlike simpler problems, Splitwise forces you to think about financial correctness: rounding errors in percentage splits can cause balances to drift by pennies, and the system must guarantee that all debts eventually net to zero.

• Strategy Pattern — model multiple split types (equal, exact, percentage) as interchangeable algorithms without modifying core expense logic
• Observer Pattern — notify users when their balance changes after a new expense is added or settled
• Command Pattern — support undoing expenses by encapsulating each expense creation as a reversible command
• Graph-based debt simplification — reduce O(N²) individual debts to at most N-1 optimal transfers using net balance computation
• UML Class Diagram — design 8-10 classes with composition, association, and inheritance relationships
• UML Sequence Diagram — trace the message flow when splitting an expense across a group
• Financial correctness — handle rounding errors in percentage splits so balances always sum to zero

Before starting this problem, make sure you're comfortable with:

• OOP Relationships — especially Composition and Association, since the expense-user-group model is heavily relationship-driven (Fundamentals S4)
• Strategy Pattern — how to encapsulate interchangeable algorithms behind a common interface (Fundamentals S12)
• Observer Pattern — how to notify dependent objects when state changes (Fundamentals S12)
• Command Pattern — how to encapsulate operations as objects for undo/redo support (Fundamentals S12)
• UML Class & Sequence Diagrams — how to read and construct both diagram types (Fundamentals S5)
• Basic graph concepts — understanding of net balances and greedy algorithms is helpful for the debt simplification tutorial

If you've completed the easy-level design problems (DP1-DP7), you're well-prepared. This problem builds directly on patterns introduced in the Task Management System (DP7), which also uses Observer and Command.

We will design: The core domain logic for expense sharing — users, groups, expenses, split strategies, balance tracking, debt simplification, and expense undo. This covers the object model that powers the backend of an app like Splitwise.

We will NOT design: Database schemas, REST APIs, mobile UI, push notification infrastructure, multi-currency conversion services, or distributed systems concerns. This is a Low Level Design (object-oriented) exercise, not a System Design (infrastructure) problem.

Key boundaries:

• Single-currency expenses (no forex conversion)
• In-memory balance tracking (no persistence layer)
• Synchronous operations (no async message queues)
• Core splitting and settlement logic only