Balance calculation algorithm in LLD - Scalability & System Analysis

Scalability Analysis - Balance calculation algorithm

Growth Table: Balance Calculation Algorithm

Users	Transactions per Second	Data Size (Accounts)	Latency Expectation	System Changes
100	10-50	1000 accounts	<100ms	Single server, simple DB queries
10,000	1,000-5,000	100K accounts	<200ms	DB indexing, caching balance results
1,000,000	50,000-100,000	10M accounts	<500ms	DB sharding, read replicas, distributed cache
100,000,000	5M+	1B+ accounts	<1s	Microservices, event sourcing, CQRS, multi-region deployment

First Bottleneck

At low scale, the database query speed limits balance calculation because each calculation requires reading transaction history or account states.

As users grow, the database CPU and I/O become overwhelmed by concurrent queries.

At very large scale, network bandwidth and data consistency across shards become bottlenecks.

Scaling Solutions

• Caching: Store frequently requested balances in fast cache (e.g., Redis) to reduce DB load.
• Read Replicas: Use database replicas to distribute read queries.
• Sharding: Split accounts across multiple database shards by user ID or account ID.
• Event Sourcing & CQRS: Separate write and read models to optimize balance queries.
• Horizontal Scaling: Add more application servers behind load balancers.
• Batch Processing: Precompute balances periodically instead of real-time calculation.

Back-of-Envelope Cost Analysis

At 1M users with 100K TPS, assuming each balance query is 1 KB data:

• Data throughput: 100,000 requests/sec * 1 KB = ~100 MB/s network bandwidth.
• Storage: 10M accounts * 1 KB/account = ~10 GB for account data.
• DB QPS: 100K QPS likely exceeds single DB capacity (5K-10K QPS), so sharding needed.
• Cache ops: Redis can handle 100K-500K ops/sec, suitable for caching balance queries.

Interview Tip

Start by clarifying the scale and latency requirements.

Identify the main data flow: how balances are calculated and stored.

Discuss bottlenecks at each scale and propose targeted solutions like caching and sharding.

Explain trade-offs between real-time calculation and precomputed balances.

Self Check

Your database handles 1000 QPS. Traffic grows 10x to 10,000 QPS. What do you do first?

Answer: Add read replicas and implement caching to reduce load on the primary database before considering sharding or more complex solutions.

Key Result

Balance calculation algorithms first hit database query limits as users grow; caching and sharding are key to scaling efficiently.