Loading low-level design…

Design Splitwise - Low-Level Design | OneNoughtOne

00:00:00

Design Splitwise

Intermediate

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.

Core Use Cases

Add users

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)

Constraints

Split amounts must sum to the total expense amount (within rounding tolerance of ¢1)
Percentage splits must sum to 100%
Share-based splits divide proportionally (amount × share / total_shares)
Balance invariant: balances[A][B] == −balances[B][A]
Cannot remove a group member with a non-zero balance in that group

Assumptions

In-memory storage (no database)
Single currency (no multi-currency conversion)
Single payer per expense (no multi-payer)
Rounding to 2 decimal places (penny rounding handled greedily)
Soft-delete for expenses (reversing balances)

In Scope

Four split strategies: Equal, Exact, Percent, Unequal (share-based)
Net balance tracking between every pair of users
Group expense management
Settlement / pay-back recording
Debt simplification (minimise transactions)
Activity log for audit trail

Out of Scope

Multi-payer (multiple people pay for one expense)
Multi-currency support
Recurring / scheduled expenses
Receipt image upload and OCR
Integration with payment gateways
Push notifications

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Loading LLD design...

00:00:00

Design Splitwise

Intermediate

Core Use Cases

Add users

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)

Constraints

Split amounts must sum to the total expense amount (within rounding tolerance of ¢1)
Percentage splits must sum to 100%
Share-based splits divide proportionally (amount × share / total_shares)
Balance invariant: balances[A][B] == −balances[B][A]
Cannot remove a group member with a non-zero balance in that group

Assumptions

In-memory storage (no database)
Single currency (no multi-currency conversion)
Single payer per expense (no multi-payer)
Rounding to 2 decimal places (penny rounding handled greedily)
Soft-delete for expenses (reversing balances)

In Scope

Four split strategies: Equal, Exact, Percent, Unequal (share-based)
Net balance tracking between every pair of users
Group expense management
Settlement / pay-back recording
Debt simplification (minimise transactions)
Activity log for audit trail

Out of Scope

Multi-payer (multiple people pay for one expense)
Multi-currency support
Recurring / scheduled expenses
Receipt image upload and OCR
Integration with payment gateways
Push notifications

Approach Guide(Click to expand each section)

Before diving into code, clarify the use cases and edge cases. Understanding the problem deeply leads to better class design.

List Core Use Cases

Identify the primary actions users will perform. For a parking lot: park vehicle, exit vehicle, check availability. Each becomes a method.

Identify Actors

Who interacts with the system? Customers, admins, automated systems? Each actor type may need different interfaces.

Clarify Constraints

What are the limits? Max vehicles, supported vehicle types, payment methods. Constraints drive your data structures.

Ask About Edge Cases

What happens on overflow? Concurrent access? Payment failures? Thinking about edge cases reveals hidden complexity.

Follow-up Questions(Questions an interviewer might ask)

💡 Draw UML class diagrams, sequence diagrams, or any design visualizations. Submit from the Code tab.

Loading canvas...

Design Splitwise

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design Splitwise

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Follow-up Questions(Questions an interviewer might ask)

Explore the full editorial.

Sign in to view submissions

Design Splitwise

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you handle multi-payer expenses (e.g. two people split the bill at checkout)?

2How would you implement multi-currency support?

3How would you optimally simplify debts (NP-hard in general)?

4How would you add recurring expenses (e.g. monthly rent)?

5How would you handle concurrency when two users add expenses simultaneously?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions

Design Splitwise

Core Use Cases

Constraints

Assumptions

In Scope

Out of Scope

Approach Guide(Click to expand each section)

Gather Requirements~3 min

Identify Classes & Entities~4 min

Define Relationships~3 min

Apply Design Patterns~4 min

Apply SOLID Principles~3 min

Code Organization~2 min

Follow-up Questions(Questions an interviewer might ask)

1How would you handle multi-payer expenses (e.g. two people split the bill at checkout)?

2How would you implement multi-currency support?

3How would you optimally simplify debts (NP-hard in general)?

4How would you add recurring expenses (e.g. monthly rent)?

5How would you handle concurrency when two users add expenses simultaneously?

Key Topics

Asked At

Explore the full editorial.

Sign in to view submissions