Practice/Stripe/Design a ledger

Design a ledger

System DesignMust

Problem Statement

You are tasked with designing a core ledger system that tracks financial transactions for a payment processing platform. The system must allow merchants to post transactions (such as payments, refunds, and transfers) and query account balances with complete accuracy and auditability. Every transaction follows double-entry accounting principles, meaning each operation creates offsetting debit and credit entries that keep the system balanced.

The ledger serves as the source of truth for all financial data. It must handle millions of transactions per day across hundreds of thousands of merchant accounts, support both real-time and historical balance queries, and maintain an immutable audit trail for regulatory compliance. The core challenge is maintaining strict correctness guarantees -- no money should ever be lost or created -- while delivering low-latency reads and high-throughput writes at scale.

Key Requirements

Functional

• Transaction Recording -- Accept and persist financial transactions as atomic double-entry operations with unique identifiers, timestamps, and associated metadata
• Balance Queries -- Retrieve current account balances instantly, and support historical point-in-time balance lookups for any past moment
• Account Management -- Create and organize accounts with hierarchical structures, currency support, and custom attributes
• Transaction History -- Query and filter complete transaction histories by date range, account, transaction type, and other criteria for reconciliation
• Idempotency -- Guarantee that duplicate transaction submissions (due to retries or network issues) do not create multiple entries

Non-Functional

• Scalability -- Support 10,000+ transactions per second with ability to scale to 100,000+ TPS; handle 1M+ active accounts
• Reliability -- Ensure 99.99% uptime with no data loss; implement redundancy and automated failover
• Latency -- Current balance queries under 100ms at p99; transaction posting under 500ms at p99
• Consistency -- Maintain strong consistency for writes (ACID transactions); eventually consistent reads acceptable for some reporting views

What Interviewers Focus On

Based on real interview experiences, these are the areas interviewers probe most deeply:

1. Double-Entry Accounting Model and Data Schema

Interviewers want to see if you understand that a financial ledger requires an immutable, append-only log of entries where every transaction creates at least two offsetting entries that maintain zero-sum balances across the system.

Hints to consider:

• Design a journal entry table that records every debit and credit with references to source transactions
• Ensure each transaction creates balanced entries (sum of debits equals sum of credits)
• Keep entries immutable after creation; corrections require new offsetting entries, never updates
• Store metadata like effective timestamp, posting timestamp, and currency alongside each entry

2. Idempotency and Exactly-Once Processing

With network retries and distributed components, clients will inevitably submit the same transaction multiple times. You must guarantee that each unique transaction posts exactly once, even under failure conditions.

Hints to consider:

• Use client-provided idempotency keys or transaction IDs to detect duplicates
• Implement atomic check-and-insert using unique constraints in the database
• Consider separate idempotency token table with expiration to track recent submissions
• Handle edge cases like partial failures where acknowledgment is lost but transaction succeeded

3. Balance Calculation and Materialization

Computing balances by summing all historical entries on every query is prohibitively expensive. You need materialized balances that can be updated efficiently while maintaining correctness under concurrent writes.

Hints to consider:

• Maintain separate balance tables that aggregate entries, updated atomically with transaction writes
• Use optimistic locking (version numbers) or pessimistic locks to prevent lost updates during concurrent transactions
• Consider periodic snapshots plus delta summation for historical balance queries
• Cache hot account balances in memory with proper invalidation on updates

4. Handling Contention on Hot Accounts

Popular merchant accounts may receive hundreds or thousands of transactions per second, creating write contention that can bottleneck the entire system if not carefully managed.

Hints to consider:

• Partition writes by account ID to isolate contention and enable parallel processing
• Use row-level locking or optimistic concurrency control rather than table-level locks
• Consider message queues to serialize writes to hot accounts while maintaining ordering
• Implement backpressure and rate limiting for accounts exceeding capacity thresholds

5. Audit Trail and Regulatory Compliance

Financial systems require complete, tamper-proof audit logs that can prove correctness to auditors and regulators. Every state change must be traceable and verifiable.

Hints to consider:

• Store who initiated each transaction, when, and from what system with full context
• Implement immutable append-only logs that cannot be altered or deleted
• Maintain checksums or cryptographic hashes to detect tampering
• Support reconstruction of any account's full history from the immutable journal
• Consider write-ahead logs and event sourcing patterns for complete auditability