# Design a Mobile Group Expense Splitter (Splitwise-Style)

Source: https://www.techinterview.org/post/3233475176/design-mobile-group-expense-splitter/
Updated: 2026-07-26 · techinterview.org

Group expense apps (Splitwise, Tricount, SettleUp) sit at the intersection of social and financial. The interview tests whether you understand the math (n-way settlement), the data model (transaction graph), and the realities of multi-currency, offline edits, and asynchronous group dynamics.

## Functional requirements

- Add expenses with split rules (equal, by share, by exact amount). Model splits as a strategy rather than hardcoded branches — an equal split is just a special case of by-share. Interviewers watch for the validation step: exact-amount splits must sum back to the expense total before you save.

- Compute who owes whom. Keep pairwise debts and a net-per-person balance; a common follow-up is which you store and which you derive. Deriving net balances on read keeps writes trivial but costs a scan of the group's expenses each time.

- Suggest minimum-transaction settlement. This is the part interviewers dig into — collapsing six tangled debts into two transfers. Expect a probe on whether the true minimum (NP-hard subset matching) is worth chasing versus the greedy max-creditor/max-debtor pass most apps actually ship.

- Multi-currency with conversion. Pin the exchange rate at the moment the expense is created so balances don't drift when rates move later. A frequent question is whether you settle in the expense's original currency or the group's primary currency.

- Group balances visible to all members. The access boundary is the group, not the individual row, so there's no per-user filtering on expenses. Be ready to explain how a balance stays consistent when two members add expenses at the same time.

- Settlement marked when paid. A settlement is its own record (from, to, amount, date), not a mutation of past expenses, so the history stays intact. Interviewers sometimes ask what happens when someone marks a payment that never arrived — usually a soft flag the other party confirms.

## Architecture

Three modules: **expense entry**, **balance calculation**, **sync**.

## Data model

Each expense:

- ID, group, payer, amount, currency, date, description

- Splits: list of (debtor, share)

Each settlement:

- From, to, amount, date

Balance per pair: sum of expenses where I owe you minus sum I have settled.

## Balance calculation

For a group of N people:

- Compute net balance per person (positive = owed, negative = owes)

- Pair max-creditor with max-debtor; settle min(their amounts)

- Repeat until balances are zero

This produces minimum number of transactions to settle. [Standard textbook problem](/algorithm-patterns-cheat-sheet/).

## Multi-currency

Each expense has a native currency. Group has a primary currency. Display converts using exchange rate at time of expense.

Real-time rates from a service (open exchange rates, currencylayer). Cache rates per day.

Settlement is in real currency (USD, EUR, etc.) — track which currency was actually paid.

## Offline editing

User adds expenses while offline. Sync later. Strategies:

- Each expense has a local UUID + server ID after sync

- Operations log: add expense, edit, delete

- Server merges; conflicts are rare for additive operations

- For edits: [last-write-wins](/post/3233460997/system-design-collaborative-editing/) by sequence number

## Multi-user sync

One user adds an expense; others see it on their devices. Push notifications wake the app; pull on foreground.

Common edge case: User A added an expense; User B edited it before A's edit synced. Conflict resolution: surface to user, offer to merge.

## Notifications

- "Alex added a $50 expense for dinner"

- "Sam paid Alex $30"

- "You owe Alex $25 for the trip"

Cap frequency to avoid spam. Aggregate ("3 new expenses in your group").

## Privacy

- Group members see all expenses in the group

- Expenses outside the group are private

- Sensitive descriptions ("medical bill") may need extra discretion

## Common gotchas

- Floating-point arithmetic for money (use integer cents)

- Rounding errors in equal splits ($10 / 3 = ?)

- Currency conversion drift over time

- Members joining mid-trip (their share starts when they join)

## Frequently Asked Questions

### How does Splitwise handle the rounding problem?

Distribute the rounding error to the payer or first member. Always sum-check that the total of splits equals the total expense.

### Should expenses be editable forever?

Most apps allow edit until settlement. After settlement, edits create a new adjustment expense.

### What about complex splits like "I had only the appetizer"?

Per-line-item splitting. Power-user feature; most apps support exact-amount or exact-shares as flexible enough.