Requirements for Splitwise

Let's define what our Splitwise system needs to do. Each requirement is specific enough to drive at least one class or method in our final design.

1. R1 — User Management: The system shall allow users to register with a unique user ID, name, email, and phone number. Each user maintains a balance sheet tracking how much they owe or are owed by every other user.

2. R2 — Group Management: Users can create groups (e.g., "Trip to Goa", "Apartment Rent") and add other registered users to them. Expenses can be added to a group or created without a group (direct between users).

3. R3 — Add Expense: A user (the payer) can add an expense specifying the total amount, a description, and the participants who share the cost. The payer may or may not be one of the participants.

4. R4 — Equal Split: The system shall support splitting an expense equally among all participants. If the amount doesn't divide evenly (e.g., $100 among 3 people), the system must handle rounding so the total still sums to the exact expense amount.

5. R5 — Exact Split: The system shall support splitting an expense by exact amounts specified per participant. The sum of all exact amounts must equal the total expense — the system rejects the expense otherwise.

6. R6 — Percentage Split: The system shall support splitting an expense by percentages specified per participant. Percentages must sum to 100%. Rounding is applied to individual shares, with the remainder assigned to the last participant to ensure correctness.

7. R7 — Balance Tracking: After every expense, the system updates the pairwise balances between the payer and each participant. A user can query their total balance (net amount owed/owing) and per-user breakdown at any time.

8. R8 — Debt Simplification: The system shall provide an algorithm to simplify debts within a group — reducing the number of transactions needed to settle all balances. For example, if A owes B $10 and B owes C$10, the simplified result is A pays C $10 directly.

9. R9 — Expense History: Users can view a chronological list of all expenses they are involved in, filtered by group or across all groups.

10. R10 — Settle Up: A user can record a payment to another user, which reduces the outstanding balance between them. Partial settlements are allowed.

Beyond functionality, our design must satisfy:

1. Financial Correctness: Split calculations must be exact — no penny should be lost or created. After every operation, the sum of all balances across all users must be zero (conservation of money). This is the single most critical invariant in the system.

2. Extensibility (Open/Closed Principle): Adding a new split type (e.g., split by shares, split by weight) must not require modifying existing split logic. The Strategy Pattern makes this possible — new strategies plug in without touching the expense creation flow.

3. Undo Support: Users should be able to undo a recently added expense, which reverses all balance changes it caused. This requires tracking the effect of each expense as a reversible operation.

4. Testability: Each component — split calculation, balance updates, debt simplification — must be testable in isolation without needing the full system running.

In Scope:

• User and group creation
• Adding expenses with equal, exact, and percentage splits
• Pairwise balance tracking between all users
• Debt simplification algorithm (minimizing transactions)
• Expense undo functionality
• Balance query (per-user and total)
• Settle-up (recording payments)

Out of Scope:

• Multi-currency support and forex conversion (system-level concern)
• Database persistence and REST API endpoints (infrastructure)
• Push notifications and email alerts (delivery infrastructure)
• User authentication and authorization (security layer)
• Receipt image upload and OCR (feature, not core domain)
• Recurring expenses and scheduled settlements (could be an extension)

We're designing the domain model — the classes and relationships that power the business logic. The API layer and database would wrap around this model but aren't part of the LLD exercise.

In a real interview, spend 3-5 minutes clarifying requirements before jumping into design. Ask questions like:

• "Should the system support splitting by shares (e.g., 2x for one person, 1x for others)?" — This tells the interviewer you're thinking about extensibility.
• "Do we need to handle the case where the payer is NOT one of the participants?" — This is a real Splitwise scenario (paying for others).
• "Is debt simplification required within a group only, or across all groups?" — Scope matters here; within-group is simpler.
• "Should we support partial settlements?" — This affects how we model the settle-up operation.
• "How should rounding work for equal splits that don't divide evenly?" — This signals financial correctness awareness.

These questions demonstrate that you understand the domain deeply and don't assume a trivial "split by N" implementation.