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.

Practice

1. What is the main purpose of a balance calculation algorithm in a financial system?

easy

A. To add credits and subtract debits from an initial amount

B. To sort transactions by date

C. To encrypt user data

D. To generate random transaction IDs

Solution

1. Step 1: Understand the role of balance calculation

   The balance calculation algorithm updates the current balance by adding credits and subtracting debits.

2. Step 2: Compare with other options

   Sorting transactions, encrypting data, and generating IDs are unrelated to balance calculation.

3. Final Answer:

   To add credits and subtract debits from an initial amount -> Option A

4. Quick Check:

   Balance calculation = add credits - subtract debits [OK]

Hint: Balance means adding credits and subtracting debits [OK]

Common Mistakes:

• Confusing balance calculation with sorting or encryption
• Thinking balance calculation generates IDs
• Ignoring subtraction of debits

2. Which of the following code snippets correctly initializes a balance variable to zero in a balance calculation algorithm?

easy

A. balance := 0

B. balance = 0

C. balance == 0

D. balance = 'zero'

Solution

1. Step 1: Identify correct assignment syntax

   In most programming languages, = assigns a value. So balance = 0 sets balance to zero.

2. Step 2: Check other options for errors

   := is not standard in many languages, == is a comparison, and assigning a string 'zero' is incorrect for numeric balance.

3. Final Answer:

   balance = 0 -> Option B

4. Quick Check:

   Use = for assignment, not == or := [OK]

Hint: Use single = to assign values in most languages [OK]

Common Mistakes:

• Using == instead of = for assignment
• Using := which is not common in many languages
• Assigning string instead of numeric zero

3. Consider this pseudocode for balance calculation:

balance = 100
transactions = [20, -10, 30, -5]
for t in transactions:
    balance += t
print(balance)

What will be the printed balance?

medium

A. 135

B. 145

C. 155

D. 125

Solution

1. Step 1: Calculate sum of transactions

   Sum = 20 + (-10) + 30 + (-5) = 20 - 10 + 30 - 5 = 35

2. Step 2: Add sum to initial balance

   Initial balance 100 + 35 = 135

3. Final Answer:

   135 -> Option A

4. Quick Check:

   100 + (20 -10 +30 -5) = 135 [OK]

Hint: Add all transactions to initial balance [OK]

Common Mistakes:

• Adding absolute values instead of signed values
• Forgetting to add initial balance
• Miscalculating sum of transactions

4. Identify the bug in this balance calculation code snippet:

balance = 50
transactions = [10, -20, 15]
for t in transactions:
    balance = t
print(balance)

medium

A. The initial balance is not set

B. The transactions list is empty

C. The balance is overwritten instead of updated

D. The loop variable is incorrect

Solution

1. Step 1: Analyze the loop operation

   Inside the loop, balance = t overwrites balance each time instead of adding.

2. Step 2: Understand correct update

   It should be balance += t to add each transaction to balance.

3. Final Answer:

   The balance is overwritten instead of updated -> Option C

4. Quick Check:

   Use += to update balance, not = [OK]

Hint: Use += to add transactions, not = [OK]

Common Mistakes:

• Using = instead of += inside loop
• Assuming transactions list is empty
• Ignoring initial balance

5. You need to design a balance calculation system that handles millions of transactions per day with real-time updates. Which design choice best supports scalability and accuracy?

hard

A. Ignore debits and only add credits to simplify calculation

B. Use a single database transaction to update balance after each transaction

C. Store all transactions in memory and recalculate balance on every request

D. Batch transactions and update balance periodically with distributed processing

Solution

1. Step 1: Consider scalability needs

   Millions of transactions require efficient processing; single updates per transaction cause bottlenecks.

2. Step 2: Evaluate batch processing benefits

   Batching with distributed processing reduces load and maintains accuracy by processing groups of transactions.

3. Step 3: Reject other options

   Single DB transactions cause slowdowns, in-memory recalculation is memory-heavy and slow, ignoring debits causes incorrect balances.

4. Final Answer:

   Batch transactions and update balance periodically with distributed processing -> Option D

5. Quick Check:

   Batch + distributed processing = scalable & accurate [OK]

Hint: Batch and distribute processing for large-scale balance updates [OK]

Common Mistakes:

• Updating balance per transaction causing bottlenecks
• Recalculating balance on every request wasting memory
• Ignoring debits leading to wrong balances