Why Splitwise tests financial logic in LLD - Design It to Understand It

Design: Splitwise Financial Logic Testing

Focus on the financial calculation logic within Splitwise, excluding UI and network layers

Functional Requirements

FR1: Ensure all calculations of debts and credits between users are accurate

FR2: Verify correct handling of different currencies and conversions

FR3: Validate splitting rules such as equal, percentage, or custom shares

FR4: Confirm correct updates on user balances after transactions

FR5: Detect and prevent rounding errors in financial computations

Non-Functional Requirements

NFR1: Tests must cover edge cases like zero amounts, negative balances

NFR2: Financial calculations should be precise to at least two decimal places

NFR3: Tests should run quickly to support continuous integration

NFR4: System must handle concurrent updates without data inconsistency

Think Before You Design

Questions to Ask

❓ Question 1

❓ Question 2

❓ Question 3

❓ Question 4

❓ Question 5

Key Components

Transaction processing module

Currency conversion service

Balance calculation engine

Rounding and precision utilities

Test framework for unit and integration tests

Design Patterns

Test-driven development (TDD) for financial logic

Mocking external currency conversion APIs

Idempotent transaction processing

Boundary value analysis for edge cases

Continuous integration with automated test suites

Reference Architecture

 +---------------------+       +-----------------------+       +---------------------+
 |  Transaction Module  | <---> |  Financial Logic Core  | <---> |  Currency Conversion |
 +---------------------+       +-----------------------+       +---------------------+
           |                             |                                |
           v                             v                                v
 +---------------------+       +-----------------------+       +---------------------+
 |  Balance Updater     |       |  Rounding & Precision  |       |  Test Suite Runner   |
 +---------------------+       +-----------------------+       +---------------------+

Components

Transaction Module

Custom business logic code

Handles input of user transactions and initiates calculations

Financial Logic Core

Core calculation engine

Performs debt splitting, balance updates, and enforces rules

Currency Conversion

External API or internal service

Converts amounts between currencies accurately

Rounding & Precision Utilities

Library or custom code

Ensures consistent rounding and decimal precision

Test Suite Runner

Unit test framework (e.g., pytest, JUnit)

Runs automated tests to verify financial logic correctness

Request Flow

1. User submits a transaction with amounts and participants

2. Transaction Module validates input and forwards to Financial Logic Core

3. Financial Logic Core calculates shares, applies currency conversion if needed

4. Rounding & Precision Utilities adjust amounts to correct decimal places

5. Balance Updater updates user balances accordingly

6. Test Suite Runner executes tests simulating these steps with various inputs

7. Test results confirm correctness or highlight errors in logic

Database Schema

Entities: User, Transaction, Balance Relationships: - User has many Transactions - Transaction involves multiple Users (participants) - Balance tracks net amount owed or owed to each User Fields: - Transaction: id, payer_id, participants, amount, currency, timestamp - Balance: user_id, net_amount, currency - User: id, name, preferred_currency

Scaling Discussion

Bottlenecks

Complexity of currency conversions with many currencies

High volume of concurrent transactions causing race conditions

Precision errors accumulating over many calculations

Slow test execution impacting development speed

Solutions

Cache exchange rates and update periodically to reduce API calls

Use locking or transactional mechanisms to handle concurrency safely

Implement fixed-point arithmetic or decimal libraries for precision

Parallelize tests and focus on critical financial logic for faster feedback

Interview Tips

Time: Spend 10 minutes explaining why financial logic testing is critical, 15 minutes designing test coverage and components, 10 minutes discussing scaling and concurrency, 10 minutes answering questions

Financial logic errors directly impact user trust and money

Testing must cover all calculation paths including edge cases

Concurrency and precision are common sources of bugs

Automated tests enable safe continuous deployment

Clear separation of concerns improves maintainability