Design a Mobile Group Expense Splitter (Splitwise-Style)

Updated July 26, 2026 · 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.

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 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.