Splitwise

Phase 1: Requirements & Use Cases

Interviewer: "Design a simplified version of Splitwise."

Candidate: "Sure. Splitwise is an expense-splitting app — users in a group add shared expenses, the system tracks who owes whom, and eventually balances are settled. Let me confirm: I'll design for groups of users adding expenses with different split types, the system tracking balances, and optionally simplifying debts. No bank integration, no currency conversion for V1?"

Interviewer: "Correct. What clarifying questions do you have?"

Candidate: "A few: What split types should I support? I'll cover EQUAL, EXACT amount, and PERCENTAGE — those are the three core Splitwise split modes. Should I model individual friendships outside groups, or only group-based expenses? I'll start group-only for clarity. Does debt simplification need to be automatic, or user-triggered? User-triggered — it's a complex optimization that I'll model as an explicit operation."

Interviewer: "What actors are in the system?"

Candidate: "Two: a User (creates expenses, settles debts, joins groups) and a Group (holds members and expenses). The system acts as the orchestrator through an ExpenseService."

Interviewer: "What if someone pays for an expense but isn't in the group?"

Candidate: "I'd require the payer to be a group member — scoping out third-party payers simplifies the balance model significantly and covers 99% of real Splitwise usage. I'll note it as a known constraint."

WHY: Allowing non-member payers requires tracking external payment obligations outside the group balance sheet. That adds significant complexity without being core to the OOD problem.

---

Core Use Cases:

1. User creates a group and…