Balance calculation algorithm in LLD - System Design Guide

Problem Statement

When a system handles multiple transactions like deposits, withdrawals, and transfers, calculating the correct balance becomes error-prone if done naively. Mistakes such as double counting, race conditions, or inconsistent state can cause incorrect balances, leading to user distrust and financial loss.

Solution

The balance calculation algorithm ensures accurate and consistent balance updates by processing transactions in a controlled order and applying atomic operations. It typically maintains a ledger of all transactions and calculates the balance by summing them or updates the balance incrementally with each transaction while preventing concurrent conflicts.

Architecture

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Transaction │──────▶│ Balance Store │──────▶│   User View   │
│    Input      │       │ (Database or  │       │ (API/Frontend)│
└───────────────┘       │  In-memory)   │       └───────────────┘
                        └───────────────┘

This diagram shows how transactions flow into the system, update the balance store, and then reflect in the user's view.

Trade-offs

✓ Pros

→

Ensures accurate and consistent balance updates even under concurrent transactions.

→

Prevents race conditions by using atomic operations or transaction logs.

→

Supports auditability by maintaining a ledger of all transactions.

✗ Cons

→

Maintaining a full transaction ledger can increase storage and processing overhead.

→

Incremental balance updates require careful concurrency control to avoid conflicts.

→

Calculating balance from the ledger on-demand can be slower than using cached balances.

Use when the system handles frequent concurrent transactions and requires strong consistency and audit trails, typically in financial or wallet systems with thousands of transactions per second.

Avoid when the system has very low transaction volume (under 100 transactions per day) where simple balance updates without concurrency control suffice.

Real World Examples

Stripe

Stripe uses precise balance calculation algorithms to ensure merchant accounts reflect accurate funds after payments, refunds, and fees, preventing financial discrepancies.

PayPal

PayPal maintains a transaction ledger and uses atomic balance updates to handle millions of concurrent transactions without errors or double spending.

Robinhood

Robinhood calculates user balances in real-time by processing trades and deposits atomically to avoid incorrect portfolio valuations.

Code Example

The before code updates balance directly without any concurrency control, risking race conditions. The after code uses a lock to ensure atomic updates and keeps a transaction ledger for audit and consistency.

LLD

### Before: naive balance update without concurrency control
class Account:
    def __init__(self):
        self.balance = 0

    def deposit(self, amount):
        self.balance += amount

    def withdraw(self, amount):
        if self.balance >= amount:
            self.balance -= amount
        else:
            raise Exception("Insufficient funds")


### After: balance update with transaction log and atomic lock
import threading

class Account:
    def __init__(self):
        self.balance = 0
        self.lock = threading.Lock()
        self.transactions = []  # ledger

    def deposit(self, amount):
        with self.lock:
            self.balance += amount
            self.transactions.append(('deposit', amount))

    def withdraw(self, amount):
        with self.lock:
            if self.balance >= amount:
                self.balance -= amount
                self.transactions.append(('withdraw', amount))
            else:
                raise Exception("Insufficient funds")

Alternatives

Event Sourcing

Stores all changes as events and rebuilds balance by replaying events instead of direct updates.

Use when: Choose when you need full audit history and the ability to reconstruct state at any point in time.

Snapshot with Incremental Updates

Periodically saves balance snapshots and applies incremental transactions to reduce computation.

Use when: Choose when transaction volume is very high and replaying all transactions each time is too slow.

Summary

Balance calculation algorithms prevent errors like double counting and race conditions in financial systems.

They use atomic operations and transaction ledgers to maintain consistent and auditable balances.

Choosing the right approach depends on transaction volume, concurrency, and audit requirements.

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