Why Splitwise tests financial logic in LLD - Scalability Evidence

Scalability Analysis - Why Splitwise tests financial logic

Growth Table: User Scale and Financial Logic Complexity

Users	Financial Logic Complexity	System Impact
100 users	Basic debt calculations, simple splits	Low load, simple validations
10,000 users	Multiple currencies, recurring payments, partial payments	Moderate load, need for accurate rounding and concurrency control
1,000,000 users	Complex group settlements, currency conversions, fraud detection	High load, strict consistency, distributed transactions
100,000,000 users	Global scale financial compliance, multi-region data consistency	Massive concurrency, partitioned data, eventual consistency trade-offs

First Bottleneck: Financial Logic Accuracy and Consistency

As user count grows, the first bottleneck is ensuring the financial calculations remain accurate and consistent.

Errors in debt calculations or rounding can cause user trust issues.

Concurrency issues arise when multiple users update shared expenses simultaneously.

This breaks the system before raw throughput or storage limits.

Scaling Solutions for Financial Logic

• Unit Testing and Automated Validation: Rigorous tests to catch calculation errors early.
• Atomic Transactions: Use database transactions to keep updates consistent.
• Optimistic Locking: Prevent race conditions on shared data.
• Microservices: Isolate financial logic in dedicated services for easier scaling and updates.
• Caching: Cache read-only financial summaries to reduce load.
• Sharding: Partition user data to reduce contention.
• Monitoring and Alerts: Detect anomalies in financial calculations quickly.

Back-of-Envelope Cost Analysis

• At 1M users, assume 10 QPS per user on average -> 10M QPS total (spread across many servers).
• Database must handle ~10,000 QPS for financial transactions (assuming partitioning).
• Storage: Each transaction record ~1KB, 10M transactions/day -> ~300GB/month storage.
• Bandwidth: Financial data updates are small (~100 bytes), but frequent; estimate 1 Gbps network needed at large scale.

Interview Tip: Structuring Scalability Discussion

Start by identifying the critical component: financial logic accuracy.

Explain how errors impact user trust and system correctness.

Discuss concurrency challenges and data consistency.

Propose solutions like transactions, locking, and microservices.

Finally, mention monitoring and testing as essential for reliability.

Self-Check Question

Your database handles 1000 QPS for financial transactions. Traffic grows 10x. What do you do first?

Answer: Implement read replicas and partition data (sharding) to distribute load and maintain transaction consistency.

Key Result

Financial logic accuracy and concurrency control become the first bottleneck as Splitwise scales; rigorous testing and transactional consistency are essential to maintain trust and system correctness.

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