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.