Splitwise System Design Interview: Questions, Architecture and Trade-offs

A Group (Weekend Trip), its Members (Asha, Ben, Cara), an Expense (who paid, total amount, currency, split type), one or more ExpenseShare rows (per-beneficiary allocated amount), a LedgerEntry per affected member per expense (the signed balance effect), and a Settlement (a repayment event). Balances are always derived from ledger entries, never stored as the primary fact.

• Why not just store a running balance field per member pair? — A stored running balance is a cache that can drift from reality (double-counted update, missed event, race condition) with no way to recompute or audit it — deriving balance from immutable ledger entries means it's always reconstructable and checkable, which a bare mutable counter is not.

Floating-point binary representations cannot exactly represent most decimal fractions, so repeated arithmetic on money as floats accumulates silent rounding error — unacceptable when the invariant is that shares must sum exactly to the total. Storing everything as an integer count of the smallest currency unit (paise for INR, cents for USD) makes all arithmetic exact integer arithmetic.

• Does this mean the UI also works in paise? — No — paise is the storage and computation representation; the presentation layer formats it back to rupees-and-paise (e.g. 10,000 paise displayed as ₹100.00) at render time, never doing money math on the formatted string.

An expense creates new debt — one payer fronted money that others owe a share of — while a settlement extinguishes existing debt via a direct repayment between two members. Both produce ledger entries, but an expense's entries are derived from a split calculation across potentially many beneficiaries, while a settlement's entries are a simple two-party, equal-and-opposite pair.

• Can a settlement ever have more than two parties? — Not as a single settlement record — a group settle-up that touches three people should be modeled as multiple two-party settlement records, keeping each one independently auditable and reversible.

Each member's equal share is ₹900 / 3 = ₹300 exactly, with no remainder. Asha paid ₹900 and owes ₹300 of it herself, so her net position is +₹600 (others owe her ₹600 total). Ben and Cara each contributed nothing but owe ₹300 each, so their net positions are −₹300 each. The group's net sums to zero: +600 − 300 − 300 = 0. The suggested repayments are Ben → Asha ₹300 and Cara → Asha ₹300.

• Why does the zero-sum property matter here specifically? — Because an equal three-way split of ₹900 divides evenly, Vector A doesn't actually exercise the rounding-remainder rule — that's Vector D's job — but the zero-sum check (net balances always sum to zero within one closed currency ledger) is the invariant that would catch a split-math bug immediately, even in this clean case.

Every ExpenseShare amount must be a non-negative integer (in minor units), and the sum of all shares must equal the expense's total amount exactly — not approximately. Vector B's taxi expense (Ben pays ₹600, shares Asha ₹100 / Ben ₹200 / Cara ₹300) validates because 100 + 200 + 300 = 600 exactly; any exact-split submission that doesn't sum to the total should be rejected at the API boundary before it ever reaches the ledger.

• Should this validation happen client-side, server-side, or both? — Both, for different reasons — client-side for fast user feedback while entering amounts, but server-side validation is the only one that's authoritative, since a client can't be trusted to enforce a financial invariant.

Percentages must sum to exactly 100.00% as stated, but the actual allocation is computed in minor units against the real total, and indivisible remainders need a documented, deterministic rule — never ad hoc rounding and never floating point. Vector D: ₹100.00 (10,000 paise) split 33.33/33.33/33.34 yields shares of 3,333 / 3,333 / 3,334 paise, which sums to exactly 10,000. The extra paisa is assigned to the member whose stated percentage was explicitly highest (33.34%), which is why the percentages themselves were chosen asymmetrically rather than three equal 33.33% shares that wouldn't sum to 100 on their own.

• What if all three percentages were stated as exactly 33.33% each (summing to 99.99%, not 100%)? — That input should be rejected at validation — stated percentages must sum to exactly 100.00%; a 99.99% total is a client input error to surface back to the user, not something the server silently patches by inventing an extra 0.01%.
• What's the general deterministic remainder rule when the leftover isn't pre-assigned by an asymmetric percentage? — A common, auditable rule is largest-remainder allocation: compute each share's exact fractional entitlement, truncate to whole minor units, then distribute the leftover minor units one each to the shares with the largest truncated fractional remainder, in a stable, documented tie-break order (e.g. by member ID) — never by floating-point rounding of the displayed percentage.

Each beneficiary is assigned an integer weight, and their share is their weight's fraction of the total weight applied to the total amount, using the same deterministic integer-remainder rule as percentage splits. Vector E: Ben pays ₹1,000, weighted Asha:Ben:Cara = 1:2:2 (total weight 5). Asha's share is 1/5 of ₹1,000 = ₹200, Ben's and Cara's are 2/5 each = ₹400 each, summing exactly to ₹1,000 with no remainder to distribute in this particular case.

• What's Vector E's resulting net balance for each member? — Ben paid ₹1,000 and owes ₹400 of it himself, so his net is +₹600. Asha owes ₹200 she didn't pay toward, net −₹200. Cara owes ₹400 she didn't pay toward, net −₹400. These sum to zero: 600 − 200 − 400 = 0.

An exact split validates against the stated total amount directly; a percentage or shares split instead validates its own internal consistency (percentages summing to 100%, weights being positive integers) and then derives amounts from the total — conflating these two validation paths risks silently accepting a shares split whose weights don't actually produce a sane allocation, or rejecting a valid percentage split by applying amount-sum rules to percentage inputs.

• Can a single expense mix split types for different members? — Not within Splitwise's conventional product model — an expense has one split type applied consistently to all its beneficiaries; mixing would require a more general per-share allocation rule type, which is a larger scope decision to call out if an interviewer pushes on it.

Net balance for a member in a group/currency is the sum of all their signed ledger entries — positive entries from expenses they paid for others, negative entries from their own share of expenses others paid, adjusted by settlements they've sent (reduces what they're owed, i.e. moves their net down... concretely: paid-for-others minus own-share, plus settlements received, minus settlements sent). A straightforward SQL aggregation (SUM(amount) GROUP BY member_id WHERE group_id = ... AND currency = ...) over the ledger-entries table computes this directly, with the ledger as the single source of truth rather than any cached counter.

• Does this aggregation need to scan the entire expense history every time? — At small scale yes, trivially; at scale this is exactly why a materialized balance projection (updated incrementally as new ledger entries arrive) replaces a full re-aggregation on every read, discussed in the scaling section.

From Vector A: Asha +₹600, Ben −₹300, Cara −₹300. Vector B adds the taxi expense (Ben pays ₹600, exact shares Asha ₹100/Ben ₹200/Cara ₹300), whose own net effect is Asha −₹100, Ben +₹400, Cara −₹300. Summing the two expenses' effects: Asha = 600 − 100 = +₹500, Ben = −300 + 400 = +₹100, Cara = −300 − 300 = −₹600. These sum to zero: 500 + 100 − 600 = 0.

• What are the four raw pairwise debts before simplification? — Ben→Asha ₹300 and Cara→Asha ₹300 from the dinner, plus Asha→Ben ₹100 and Cara→Ben ₹300 from the taxi — four separate pairwise obligations that the combined net balance (and simplification) collapses down to far fewer actual suggested transfers.

Simplification operates on net balances, not on the raw pairwise history — once you know Asha is net +₹500, Ben is net +₹100, and Cara is net −₹600, a greedy algorithm repeatedly matches the largest debtor against the largest creditor: Cara (owes 600) pays the biggest creditor Asha (owed 500) the full ₹500, zeroing Asha out and leaving Cara owing ₹100; then Cara pays the remaining creditor Ben the remaining ₹100, zeroing both out. Result: Cara → Asha ₹500, Cara → Ben ₹100 — two transfers instead of the four original pairwise debts (Ben→Asha 300, Cara→Asha 300, Asha→Ben 100, Cara→Ben 300), with the same net effect on every member's balance.

• Is this simplified version provably the minimum number of transfers for every possible input? — No — greedy largest-debtor-vs-largest-creditor matching is not provably minimal in transaction count for every input; there are balance configurations where a smarter pairing (exploiting exact-cancellation subsets) achieves fewer transfers than greedy does. Greedy is simple, fast, and good enough for small-to-medium groups, but the claim of global minimality must not be made without proof.
• Does simplification change who is net positive or negative? — No — simplification only changes which specific transfers are suggested to settle the group; every member's net balance before and after simplification is identical by construction, since simplification is a suggestion derived from, not a replacement for, the net positions.

It's always a suggestion, never a forced transfer — the system can display "Cara owes Asha ₹500 and Ben ₹100" as the simplest way to settle, but Cara is free to instead pay Ben first, or pay less than the full amount, or use the original unsimplified pairwise view if the product exposes one; the ledger and balance derivation don't change based on which suggestion a member follows.

• Does simplification need to be recomputed after every new expense? — Yes, conceptually — simplification is a function of the current net balances, so any new expense or settlement that changes a net balance should be reflected in the next simplification view; whether it's recomputed on every read or incrementally maintained is an implementation/scaling choice, not a correctness one.

Starting from Vector B's net (Asha +₹500, Ben +₹100, Cara −₹600), a ₹200 settlement from Cara to Asha reduces what Cara owes and reduces what Asha is owed by the same amount: Asha's net drops to +₹300, Cara's net rises (becomes less negative) to −₹400, Ben is unaffected at +₹100. These still sum to zero: 300 + 100 − 400 = 0. The remaining suggested repayments are Cara → Asha ₹300 and Cara → Ben ₹100.

• Does a settlement produce ledger entries the same way an expense does? — Yes — a settlement of ₹200 from Cara to Asha produces a pair of signed ledger entries (Cara −₹200 effect on what she's owed/owes, Asha +₹200 reciprocal effect) that are summed into net balance exactly like expense-derived entries, keeping the ledger the single source of truth for both event types.

The client generates a scoped idempotency key (e.g. a UUID tied to this specific creation attempt) and sends it with the create-expense request; the server stores that key, atomically, in the same transaction that inserts the expense, its shares, and its ledger entries. If a retry arrives with the same key, the server returns the already-committed result without re-inserting anything — exactly one committed expense, one ledger effect, one activity-feed entry, never zero and never two. A retry with the same key but a materially different payload (e.g. a different amount) returns a documented conflict response rather than silently applying the new payload.

• Where does the idempotency key get checked — before or inside the database transaction? — Inside, as part of the same atomic transaction that writes the expense — checking it outside the transaction (read-then-write) leaves a race window where two concurrent retries could both pass the check before either commits, producing exactly the duplicate the mechanism was meant to prevent.

A unique constraint on the idempotency key column (scoped to, e.g., the group and the requesting member) at the database level — the insert attempt for a duplicate key fails with a constraint violation, which the application layer catches and translates into "return the existing result" rather than relying purely on an application-level check-then-insert that's vulnerable to a race.

• What should the API return on a genuine conflict (same key, different payload)? — A distinct, documented conflict status (e.g. 409) with enough detail for the client to understand its retry doesn't match what was already committed — silently accepting the new payload under the old key would let a client's bug (or bad retry logic) overwrite a correct, already-settled expense.

The expense row carries a version number; both concurrent edit requests read the expense at version 4 and submit their update conditioned on "only apply if current version is still 4." The database enforces this as an atomic compare-and-set (e.g. an UPDATE ... WHERE id = ? AND version = 4 that also increments version to 5). Exactly one of the two requests' WHERE clause matches and succeeds, taking the row to version 5; the other's UPDATE affects zero rows, and the server returns an explicit version-conflict response to that second caller rather than silently merging or silently discarding either edit.

• What's the losing client's documented retry path? — Re-fetch the expense at its new current version (5), inspect what the winning edit changed, and decide whether to reapply its own intended change on top of the new state or abandon it — never blindly retry the exact same version-4-conditioned request, since that will fail identically every time.

Expense edits are infrequent relative to reads, and holding a pessimistic lock across a user-facing edit flow (open the edit form, change a field, submit) would hold that lock for an unpredictable, potentially long duration while a human is involved — optimistic concurrency only pays a cost when an actual conflict occurs, which is rare, and keeps the common uncontended case fast and lock-free.

• Is there a scenario where pessimistic locking would be the better choice? — If edits were extremely frequent and contention on the same expense were common (unlikely for this domain), the retry storm from optimistic conflicts could itself become a bigger cost than briefly serializing access with a lock — worth naming as the trade-off's break-even condition rather than treating optimistic concurrency as universally correct.

At small scale, aggregating ledger entries on every balance read is simple and correct. At real scale, that aggregation becomes expensive to repeat on every page view, so a materialized balance projection — updated incrementally as each new ledger entry commits — serves reads cheaply. The ledger itself remains the append-only source of truth either way; the projection is a derived, rebuildable cache of it, not a replacement for it.

• What happens if the projection and the ledger ever disagree? — The ledger wins, always — a disagreement means the projection has a bug or has fallen behind, and the fix is replaying the ledger to rebuild the projection, never patching the ledger to match whatever the projection currently shows.

When creating an expense needs to both commit the ledger entries and reliably notify a downstream consumer (a balance-projection updater, a push-notification service) without risking a split where the ledger commits but the notification is silently lost, a transactional outbox writes the ledger change and an outbox event row in the same database transaction. A separate relay process then reads unpublished outbox rows and publishes them to the message bus, retrying until acknowledged — guaranteeing the notification is eventually sent if and only if the ledger write actually committed.

• Why not just publish to the message bus directly inside the request handler? — A direct publish that happens after the database commit risks the process crashing between the two steps, silently losing the downstream notification even though the ledger entry is correctly committed — the outbox pattern removes that window by making the event durable in the same transaction as the fact it describes.

The same idempotency discipline as expense creation itself — each outbox event carries a unique, durable event ID, and the projection updater checks (and records) that ID before applying the event's effect, making redelivery a safe no-op rather than a double-counted balance update.

• Does this mean the message bus needs to guarantee exactly-once delivery? — No — at-least-once delivery from the bus is sufficient as long as the consumer-side idempotency check is correct; building a duplicate-consumer-safe handler is strictly easier and more robust than trying to guarantee exactly-once delivery at the transport layer.

Each ledger entry and each projection-applied event should carry a strictly increasing sequence number per affected aggregate (e.g. per group); the projection updater tracks the last-applied sequence number and rejects or buffers an event that arrives out of order relative to it, rather than applying it and silently corrupting the running balance. If out-of-order application is detected after the fact, the clean fix is rebuilding the projection from the ledger from scratch (or from the last known-good checkpoint), not attempting to patch the drifted value in place.

• Is a full rebuild always necessary, or can you resync incrementally? — A full rebuild is the simplest correct answer and a reasonable default for a moderately sized group's history; at larger scale, a snapshot-plus-replay-from-checkpoint approach (replay only the events after the last verified-good snapshot) avoids reprocessing the entire history every time.

The simplest reliable guarantee is routing that member's immediate post-write balance read to the same source that just accepted the write (the primary, or a replica that's confirmed caught up to that write's sequence number) rather than to an arbitrary, possibly-lagging replica — other group members' views can tolerate a small, explicitly bounded staleness window, but the acting member's own immediate view should not show a stale pre-write balance.

• Does this requirement conflict with using read replicas for scale? — Not if the write path returns (or the client can request) a version/sequence token the client then uses to ensure subsequent reads are served from a replica caught up to at least that point — a form of session-level read-your-writes consistency layered on top of generally-asynchronous replica reads.

A cache in front of frequently-viewed group balances (e.g. the group summary screen) reduces load on the projection store, but it introduces an explicit staleness window that must be bounded and ideally invalidated proactively on new ledger writes for that group — the risk being a member viewing a cached balance that doesn't yet reflect an expense they or someone else just added, which is acceptable only if it's a known, short, stated window rather than an unbounded or silent one.

• Should the cache ever be the source consulted before a settlement decision? — No — a user deciding how much to actually pay someone should see the freshest available balance, not a cached one; a settlement-flow read should bypass or force-refresh the cache even if the general balance view tolerates a short cache TTL elsewhere.

Per-group sharding is the natural fit, since almost every read and write (expenses, balances, simplification) is scoped to one group at a time, and groups are naturally independent of each other — a group's entire ledger, membership, and projection can live together on one shard, keyed by group ID, avoiding cross-shard transactions for the overwhelming majority of operations.

• What operation doesn't fit cleanly into per-group sharding? — A member's cross-group activity feed or a global "total you owe across all your groups" summary requires fanning out across every shard that holds a group the member belongs to and aggregating client-side or in a dedicated aggregation service — a deliberate, named exception to the otherwise-clean per-group sharding model.

They are never combined — INR and USD are separate currency positions with separate ledgers, even within the same group, and the system must never net them together into one number without an explicit conversion event and a stated exchange-rate policy. A UI might choose to display both side by side, but internally and in any balance computation they remain two independent zero-sum ledgers.

• If the product eventually wants a single-currency summary view, how would that work correctly? — Via an explicit, timestamped conversion using a stated, auditable exchange rate source applied only for display purposes — the underlying ledgers stay in their original currencies untouched, and the converted summary is clearly presented as a converted estimate, not as if it were a native combined balance.

Exchange rates move continuously, so any netted combined balance is only ever accurate as of the rate snapshot used to compute it, and a later settlement in one currency against a balance derived partly from a converted other currency creates ambiguity about which rate should apply to the actual repayment — this is a real product and correctness question, not an oversight, and the safest default is keeping currencies strictly separate until there's an explicit product decision and a documented rate policy.

• Should a group even be allowed to mix currencies by default? — That's a legitimate product-level question to raise rather than assume — some products disallow mixed-currency groups entirely to sidestep this, while others allow it and explicitly surface per-currency balances; naming this as a decision point is itself a strong interview signal.

A settlement record has an explicit state machine: a pending state (initiated, provider processing) and a confirmed state (provider's authoritative confirmation event received), and only the confirmed state is allowed to reduce the visible, authoritative balance. A pending settlement must not reduce confirmed balances — it can be shown as "pending" in the UI so the user isn't confused, but the ledger's authoritative net balance stays unchanged until confirmation arrives. A failed payment must never be treated as settled; it should transition to a failed state that also does not affect the balance.

• What's the concrete risk of letting a pending payment reduce the balance immediately? — If the payment subsequently fails (insufficient funds, provider timeout, reversal), the balance would have shown a false settled state in the interim — a member could reasonably believe a debt is cleared when it isn't, which is exactly the kind of silent financial-correctness bug this design must prevent by keeping pending and confirmed as genuinely different states with different effects.
• Who or what is authoritative for the confirmation event? — The payment provider's callback/webhook is the authoritative confirmation source when real payments are in scope — a user simply clicking "mark as paid" in the UI is a self-asserted settlement, which the design should treat as a distinct, lower-trust event type from a provider-confirmed one, unless the product explicitly allows self-assertion as sufficient.

The settlement should not be stuck in pending forever on faith alone — a reconciliation job should periodically query the provider's status API for any settlement that's been pending longer than an expected window, resolving it to confirmed or failed based on the provider's actual record, rather than relying solely on a webhook that might never arrive.

• Is there a risk of double-confirming a settlement from both the webhook and the reconciliation job? — Only if confirmation isn't itself idempotent — the same "mark this settlement confirmed" operation triggered by either path should be a safe no-op if the settlement is already confirmed, exactly mirroring the idempotency discipline used for expense creation.

The correction is modeled as a reversal event, not an in-place deletion — the original expense, its original ledger entries, and a new reversal event (that posts the exact opposite ledger effect) all remain permanently in the audit trail. The net balance effect of that expense is now zero (its original +600/−300/−300 effect is exactly cancelled by the reversal's −600/+300/+300), but nothing about the original expense or the fact that it was reversed is ever erased from history.

• Why not just delete the row from the database? — A hard delete destroys the audit trail and makes it impossible to later answer "why did the balance look different last Tuesday" or to investigate a dispute — versioned reversal-plus-replacement preserves full history while still achieving the correct current-state balance effect.

Object-level authorization scoped to group membership, checked on every read and write — not just authentication that the caller is a valid logged-in user. Every expense, settlement, and balance query must verify the requesting user is actually a member of the group that resource belongs to, since authentication alone ("you're logged in") says nothing about whether you belong to this particular group.

• What's a concrete exploit if only authentication were checked? — Any logged-in user could query or manipulate any group's expenses by guessing or enumerating group/expense IDs, since there'd be no per-request check that they actually belong to that group — a classic broken-object-level-authorization (BOLA) vulnerability.

A client creates the expense locally with a client-generated idempotency key and a locally-assigned temporary ID, queues it, and submits it once connectivity returns through the same idempotent create-expense path already designed for Vector F — the server-side idempotency key handling means a sync retry after a dropped connection is still safe. If the same expense was independently edited by someone else while the client was offline, the sync submission is just another concurrent-edit case, handled the same way as Vector G.

• What should the offline client show the user before sync completes? — A clearly marked pending-sync state on that expense and in any balance view that includes it, so the user isn't misled into thinking it's already reflected in the group's authoritative, synced balance.

Since every legitimate expense and settlement is individually zero-sum by construction, a true violation means either a partially-applied write (some ledger entries for one event committed, others didn't — a transaction atomicity bug), a bug in a specific split type's rounding logic that silently dropped or added a minor unit, or a projection that's drifted from the ledger. The investigation path: recompute the balance directly from raw ledger entries (bypassing any projection) to confirm whether the ledger itself is unbalanced or just the projection is stale; if the ledger itself is unbalanced, find the specific expense or settlement whose own entries don't net to zero.

• What's the actual repair, once the offending event is found? — Never edit the broken ledger entries in place — post an explicit, audited correcting entry (or a full reversal-and-replacement, per Vector I's pattern) that brings the net back to zero, with the correction itself fully traceable to the investigation that found it.

Build the new projection from the existing ledger as a backfill, then run both the old live-aggregation path and the new projection in parallel for a verification window, comparing their outputs for every group and flagging any discrepancy before cutting reads over to the projection — never a hard cutover based on "it looks right" in a quick spot check, given how much financial correctness is riding on it.

• What's the highest-risk case to specifically verify during that parallel-run window? — Groups that exercise all four split types together and have had at least one correction/reversal — a migration that handles simple equal-split, never-edited groups correctly but subtly mishandles a percentage-split group with a reversal in its history is exactly the kind of regression a casual spot check misses.

Notifications should be driven off the same outbox/event pipeline as projection updates, but coalesced and filtered per-member rather than fired on every single ledger entry — e.g. a batch of near-simultaneous expense edits shouldn't trigger five separate pushes to every group member; a short coalescing window and relevance filtering (only notify members whose own balance actually changed) keep this from becoming noise.

• Should a settlement confirmation always notify immediately, bypassing coalescing? — That's a reasonable product-level exception to name — a settlement moving from pending to confirmed is often higher-signal and lower-frequency than routine expense edits, so treating it as an immediate, uncoalesced notification is a defensible, explicit choice rather than an inconsistency.

Yes — this is a correctness-and-auditability-driven choice, not a cost-driven one. Unlimited budget buys more replicas, lower projection lag, and more generous caching, but it doesn't remove the need for an authoritative, replayable, append-only record that corrections, audits, disputes, and recovery all depend on; a mutable "just update the balance field" design would still be the wrong choice even with infinite compute, because the risk it carries is about correctness and trust, not throughput.

• What would unlimited budget actually change, then? — Lower read latency via more aggressive per-group caching and replication, faster projection catch-up after a rebuild, and more generous reconciliation-job frequency against payment providers — all performance and operational levers, not a different correctness model.

Watch for the actual measured signal — sustained elevated write latency on expense creation, or storage/throughput pressure on the node holding the ledger — rather than picking an arbitrary group-count or expense-count threshold in advance; because the domain is naturally shardable per group, the practical response is moving to per-group sharding (as discussed above) once that signal appears, with the same zero-regression verification discipline used for the projection migration.

• Is there a simpler lever to try before sharding? — Read replicas for the heavy read traffic (balance views, activity feeds) can absorb significant load before the ledger's write path itself becomes the bottleneck, since in this domain reads meaningfully outnumber writes — worth naming as the cheaper first step before committing to a sharding migration.