Why Splitwise tests financial logic in LLD - Why This Architecture

Problem Statement

When financial calculations are incorrect, users lose trust and money can be misallocated. Small errors in splitting bills or rounding can cause disputes and damage the app's reputation.

Solution

Splitwise tests financial logic by writing automated tests that verify calculations for splitting expenses, rounding, and settling debts. This ensures accuracy and consistency in all money-related operations before changes reach users.

Architecture

Codebase

→Financial Logic

↓

Developers

This diagram shows how developers write code that includes financial logic, which is then verified by automated tests producing test results to ensure correctness.

Trade-offs

✓ Pros

→

Prevents costly financial errors that harm user trust.

→

Catches bugs early before deployment, reducing hotfixes.

→

Ensures consistent behavior across different devices and updates.

✗ Cons

→

Requires extra development time to write and maintain tests.

→

Complex financial rules can make tests hard to cover fully.

→

May slow down deployment pipelines due to test execution time.

Always use when handling money or financial calculations, especially if the app manages user debts or payments at scale (thousands+ users).

Not needed for non-financial features or prototypes without real money handling.

Real World Examples

Splitwise

Tests financial logic to ensure accurate splitting of bills and debt settlements among friends, preventing disputes.

Stripe

Extensive financial logic tests to guarantee correct payment processing and fee calculations.

Venmo

Tests ensure peer-to-peer payment calculations and balance updates are accurate and secure.

Code Example

The before code lacks tests, risking unnoticed errors. The after code adds unit tests that check the split method for correct division and rounding, ensuring financial logic correctness.

LLD

### Before: No tests for financial logic
class Expense:
    def __init__(self, total, participants):
        self.total = total
        self.participants = participants

    def split(self):
        return self.total / len(self.participants)


### After: Adding tests to verify splitting logic
import unittest

class Expense:
    def __init__(self, total, participants):
        self.total = total
        self.participants = participants

    def split(self):
        # Round to 2 decimals for currency
        return round(self.total / len(self.participants), 2)

class TestExpense(unittest.TestCase):
    def test_split_even(self):
        expense = Expense(100, ['A', 'B', 'C', 'D'])
        self.assertEqual(expense.split(), 25.00)

    def test_split_rounding(self):
        expense = Expense(100, ['A', 'B', 'C'])
        self.assertEqual(expense.split(), 33.33)

if __name__ == '__main__':
    unittest.main()

Alternatives

Manual Testing

Relies on human testers to verify financial calculations instead of automated tests.

Use when: Only for very small projects or early prototypes where automation is not feasible.

Property-Based Testing

Tests financial logic by checking properties and invariants over many random inputs rather than fixed examples.

Use when: When financial rules are complex and need broad input coverage.

Summary

Financial logic errors cause user distrust and money loss.

Automated tests verify calculations and rounding to ensure accuracy.

Splitwise and other payment apps rely on these tests to prevent disputes.