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

Practice

1. Why does Splitwise test its financial logic thoroughly?

easy

A. To ensure money calculations are accurate and users trust the app

B. To make the app load faster

C. To improve the app's color scheme

D. To add more social features

Solution

1. Step 1: Understand the purpose of financial logic testing

   Financial logic testing ensures that calculations involving money are correct and reliable.

2. Step 2: Connect testing to user trust

   Accurate calculations build user trust because users rely on the app for managing shared expenses.

3. Final Answer:

   To ensure money calculations are accurate and users trust the app -> Option A

4. Quick Check:

   Financial accuracy = User trust [OK]

Hint: Focus on why money accuracy matters most [OK]

Common Mistakes:

• Confusing financial logic with UI improvements
• Thinking testing improves app speed
• Assuming testing adds features

2. Which part is NOT typically included in a good test for financial logic in Splitwise?

easy

A. Changing the app's theme colors during the test

B. Action that performs a money calculation

C. Verification that results match expected values

D. Setup of initial balances and debts

Solution

1. Step 1: Identify typical test components

   Good tests include setup, action, and verification steps to check correctness.

2. Step 2: Recognize unrelated actions

   Changing theme colors is unrelated to financial logic and does not belong in such tests.

3. Final Answer:

   Changing the app's theme colors during the test -> Option A

4. Quick Check:

   Test steps = Setup + Action + Verify [OK]

Hint: Remember tests focus on logic, not UI changes [OK]

Common Mistakes:

• Including UI changes as part of logic tests
• Ignoring verification steps
• Skipping setup of test data

3. Given this test snippet for Splitwise financial logic:

initial_balance = 100
expense = 40
new_balance = initial_balance - expense
assert new_balance == 60

What will happen if the assertion fails?

medium

A. The test passes silently

B. An error is raised indicating a failed test

C. The app crashes permanently

D. The balance is automatically corrected

Solution

1. Step 1: Understand assertion behavior

   An assertion checks if a condition is true; if false, it raises an error.

2. Step 2: Connect assertion failure to test result

   If the assertion fails, the test framework reports an error indicating failure.

3. Final Answer:

   An error is raised indicating a failed test -> Option B

4. Quick Check:

   Assertion fail = Error raised [OK]

Hint: Remember assert stops test on failure [OK]

Common Mistakes:

• Thinking assertion failure passes silently
• Assuming app crashes permanently
• Believing balance auto-corrects

4. In a Splitwise test, this code snippet is used:

balance = 50
expense = '30'
new_balance = balance - expense

What is the main problem here?

medium

A. The balance variable is not initialized

B. The expense should be added, not subtracted

C. Subtracting a string from an integer causes a type error

D. The new_balance variable is unused

Solution

1. Step 1: Identify data types involved

   balance is an integer, expense is a string representing a number.

2. Step 2: Understand subtraction operation rules

   Subtracting a string from an integer is invalid and causes a type error in most languages.

3. Final Answer:

   Subtracting a string from an integer causes a type error -> Option C

4. Quick Check:

   Type mismatch in subtraction = Error [OK]

Hint: Check data types before arithmetic operations [OK]

Common Mistakes:

• Ignoring type mismatch errors
• Assuming variables are uninitialized
• Confusing addition and subtraction

5. Splitwise wants to test a complex scenario where multiple users owe each other different amounts. Which approach best ensures the financial logic is tested correctly?

hard

A. Skip tests and rely on manual checks

B. Test only single user transactions repeatedly

C. Test UI elements without checking calculations

D. Create test cases with multiple users, set debts, perform calculations, and verify final balances

Solution

1. Step 1: Understand the need for realistic test scenarios

   Testing multiple users with debts simulates real app usage and catches complex bugs.

2. Step 2: Verify calculations and final balances

   Performing calculations and verifying results ensures the financial logic works end-to-end.

3. Final Answer:

   Create test cases with multiple users, set debts, perform calculations, and verify final balances -> Option D

4. Quick Check:

   Realistic multi-user tests = Accurate financial logic [OK]

Hint: Test real-world scenarios with multiple users [OK]

Common Mistakes:

• Testing only simple cases
• Skipping automated tests
• Focusing on UI over logic