Why Splitwise tests financial logic in LLD - Architecture Impact

System Overview - Why Splitwise tests financial logic

Splitwise is an app that helps friends share expenses and keep track of who owes what. Testing financial logic ensures that calculations for debts, payments, and balances are accurate and fair. This prevents mistakes that could cause confusion or disputes among users.

Architecture Diagram

User
  |
  v
Load Balancer
  |
  v
API Gateway
  |
  v
Financial Logic Service <-> Cache
  |
  v
Database
  |
  v
Notification Service

Components

User

client

Person using the app to add expenses and view balances

Load Balancer

load_balancer

Distributes incoming user requests evenly to backend services

API Gateway

api_gateway

Routes requests to appropriate services and handles authentication

Financial Logic Service

service

Calculates debts, payments, and balances between users

Cache

cache

Stores recent financial calculations to speed up responses

Database

database

Stores user data, expenses, and transaction history

Notification Service

service

Sends alerts to users about updates or payments

Request Flow - 11 Hops

User → Load Balancer

Load Balancer → API Gateway

API Gateway → Financial Logic Service

Financial Logic Service → Cache

Cache → Financial Logic Service

Financial Logic Service → Database

Database → Financial Logic Service

Financial Logic Service → Cache

Financial Logic Service → API Gateway

API Gateway → User

Financial Logic Service → Notification Service

Failure Scenario

Component Fails:Database

Impact:New expense data cannot be saved; cache may serve stale balances; users cannot see updated balances

Mitigation:Use database replication for failover; serve cached data for reads; queue writes for retry when DB recovers

Architecture Quiz - 3 Questions

Which component checks if recent financial calculations are already available to speed up responses?

A Notification Service

B Cache

C Load Balancer

D API Gateway

Design Principle

This architecture shows the importance of caching and service layering to ensure fast and accurate financial calculations. Testing financial logic is critical because it directly affects user trust and fairness in shared expenses.

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