Splitwise System Design Trade-offs and Architectural Decisions

Weekend Trip's app could be built many ways structurally long before 10M users ever shows up. The topology chosen at the start determines how painful every later split is — and whether it's even needed.

At 5M writes/day and 20M reads/day, none of the three choices is forced by raw throughput alone — a single well-indexed relational database can handle that volume. The real question is organizational and evolutionary, not whether scale is physically possible under a monolith.

Every expense, ledger entry, and balance projection needs a storage engine, and the choice is not neutral once invariants like shares-sum-to-total-exactly and zero-sum-per-closed-ledger are involved.

Every other decision on this page depends on what the system treats as authoritative when a dispute, correction, or crash occurs. Vector I makes the requirement concrete: reversing the ₹900 dinner must restore zero net effect while keeping an audit trail — which is only possible if something durable records what happened, not just what the balance currently is.

Given ledger entries are truth, does a balance read sum the relevant entries live, or read from an already-maintained projection table?

At roughly a 4:1 read-to-write ratio, live aggregation does not stay cheap once a group's ledger history grows past a season or two of activity — Weekend Trip's own history stays small, but a user running many long-lived groups accumulates thousands of entries over time.

Vector B shows the combined picture — Asha +₹500, Ben +₹100, Cara −₹600 — only becomes actionable settlement (Cara→Asha ₹500, Cara→Ben ₹100) once the system knows the underlying pairwise contributions, not just each person's net. What does the ledger actually store as the unit of debt?

Once pairwise debts are known, the simplified debt graph — who should pay whom to settle up — can be computed fresh every time it's viewed, or computed once and stored.

Debt simplification preserves net positions, not provenance, and is explicitly a suggestion, never a forced transfer — but even restricted to that, 'fewest possible transactions' is a real optimization problem, and greedy's non-minimality deserves a direct comparison.

Integer minor units only is a core invariant of this design, and it's worth seeing exactly why the alternatives fail, not just asserting the rule.

Vector D — ₹100 split 33.33/33.33/33.34%, landing on 3,333/3,333/3,334 paise — requires a specific rule for where the leftover minor units go, because shares must sum to the total exactly, every time.

When an expense is recorded, does the request wait for the balance projection to update before returning success, or is the ledger append itself the acknowledgment boundary, with the projection update following asynchronously?

20M balance reads a day against 5M expense writes a day is a read-heavy ratio — the classic argument for serving reads from replicas or caches that lag slightly behind. But slightly stale money is a different kind of cost than slightly stale content elsewhere in a product.

Vector G: Asha and Ben concurrently edit the same version-4 expense. One must win as version 5, and the other must get an explicit, actionable conflict — never a silently lost edit, never silent corruption.

Weekend Trip's own concurrent-edit rate is inherently low — three people rarely edit the same expense in the same second — but the mechanism has to be correct regardless of frequency, because a rare bug that silently drops an edit to a shared expense erodes trust in the product's core promise.

Vector I requires that reversing the ₹900 dinner restores zero net effect while keeping an audit trail — the same reasoning any financial ledger needs for correcting a mistake after the fact.

Deleting an expense entirely is a special case of correction, and deserves its own look because 'delete' sounds like it should mean gone — which is in tension with the ledger's immutability.

Vector F requires that retrying an idempotency key produces exactly one committed expense, which starts with a decision about who generates the identifiers involved in the first place.

The mechanism promised by Decision 15 still needs to actually work, which means weighing it against the easier-looking but unreliable alternative.

Once Decision 10 writes a ledger entry and its primary balance projection synchronously, every other downstream consumer — notifications, activity feed, cross-group aggregation, analytics — still needs to find out an expense happened. How that event leaves the database is its own decision.

The same reasoning that makes idempotent ingestion non-negotiable (Decision 16) applies again at the outbox relay's own publish step.

With 20M balance reads a day, something in front of the primary balance projection is probably going to end up caching results — the question is whether that cache is a blunt TTL, or a model that actually knows when it's stale.

At 10M users and 5M expense writes a day, 'everything on one database' eventually stops being viable for at least the busiest slice of data, and the unit of partitioning matters because it has to match the access pattern already established — ledger entries and balance projections are group-scoped.

A user in several groups — a trip group, a roommates group, a book club — will want to see roughly how much they owe or are owed across everything. Does the system actually net balances across groups, or only ever aggregate group-local truths for display?

Vector H is explicit: ₹1,000 and $20 are separate ledgers, never netted implicitly. The product still reasonably wants to show something coherent to a user holding balances in more than one currency.

Vector C — Cara repays ₹200 to Asha — has to get entered into the ledger somehow, and 'somehow' ranges from a pure self-report to a fully provider-confirmed transaction.

Vector J: a pending payment never reduces the confirmed balance, and a failed payment is never treated as settled. The settlement workflow needs explicit states, not just a boolean settled-or-not.

When Ben records a payment, how quickly and by what channel do Asha and Cara find out their balance changed?

An expense can carry a receipt photo — where does that file actually live?

The immutable ledger that correctness depends on is in direct tension with a user's reasonable expectation — and in some jurisdictions, legal right — to have their personal data deleted.

Should Weekend Trip's expense-splitting core be built from scratch, or built on top of existing double-entry ledger infrastructure?

This module's whole design — ledger entries, pairwise balances, reversal-not-mutation corrections, zero-sum invariants — is itself built on long-established double-entry bookkeeping principles. The real choice was never inventing accounting from nothing versus using someone else's accounting platform; it's how directly to borrow those principles versus adopting a platform's specific abstractions wholesale.

Most of the 28 decisions above are genuinely workload-dependent — a different scale, a different product shape, or a different team's constraints could reasonably flip them. A smaller set is load-bearing: get these wrong and the rest of the design doesn't hold together, regardless of scale. This ADR table covers that smaller set.