Bird
Raised Fist0

Design a Digital Wallet System - Double-Entry Ledger, Consistency, Reconciliation

HLDhardInterview freq: high
Choose your preparation mode4 modes available
ArchitectureTraceChallenge
🏗️
Design a Digital Wallet System - Double-Entry Ledger, Consistency, Reconciliation
Design a highly consistent, scalable digital wallet system with double-entry ledger and reconciliation
hardFinancial and Real-Time SystemsFreq: high
Prerequisites:System Design FundamentalsCAP TheoremDistributed TransactionsEventual Consistency vs Strong Consistency
⚙️
Functional Requirements
  • Support atomic double-entry ledger transactions ensuring debit and credit entries are always balanced.
  • Provide APIs for wallet balance inquiry, fund transfer, and transaction history retrieval.
  • Ensure strong consistency and isolation for concurrent wallet operations to prevent overdrafts and double spends.
  • Implement periodic reconciliation to detect and correct ledger inconsistencies or missing entries.
  • Support multi-currency wallets with currency conversion rates.
  • Provide audit logs for all financial transactions for compliance and traceability.
📊
Non-Functional Requirements
  • System must support 2 billion daily active users (DAU).
  • Write throughput: 2B users × 40 transactions/user/day = 80B transactions/day.
  • Peak write QPS estimated at 1.2 million writes/sec (peak 50% higher than average).
  • Read latency P99 under 100ms for balance and transaction queries.
  • System availability SLA of 99.99% with zero data loss on failures.
❓
Clarifying Questions to Ask
  • What is the expected transaction size and average payload per ledger entry?
  • Are transactions limited to peer-to-peer transfers or include merchant payments?
  • Is strong consistency required globally or per user region?
  • What is the maximum acceptable reconciliation window (e.g., daily, hourly)?
  • Are offline transactions or eventual consistency modes allowed?
  • What compliance or audit regulations must the system satisfy?
Out of Scope
✗ Integration with external payment gateways and banks.
✗ Fraud detection and risk scoring mechanisms.
✗ User authentication and authorization systems.
✗ Mobile app or frontend UI design.
📌
Assumptions
  • Average 40 transactions per user per day.
  • Average transaction record size: 100 bytes (including metadata).
  • 2 billion daily active users.
  • Replication factor of 3 for durability.
⚡
QPS Calculation
write qps2B users × 40 tx/day ÷ 86400 sec/day ≈ 925,926 writes/sec
peak write qps925,926 × 1.3 (peak factor) ≈ 1,203,704 writes/sec
read qpsAssuming 3 reads per write (balance + history + audit) ≈ 3.6M reads/sec
💾
Storage Estimate
daily storage80B tx × 100 bytes = 8,000 GB/day ≈ 8 TB/day
retention period365 days
total storage8 TB/day × 365 days = 2,920 TB ≈ 2.9 PB
with replication2.9 PB × 3 = 8.7 PB total storage
🖥️
Server Estimate
write pathKafka cluster with 1000 brokers (each 1.2K writes/sec capacity) to handle 1.2M writes/sec peak
storage nodesCassandra cluster with 2000 nodes (each 4 TB usable storage) to store 8.7 PB replicated data
🏗️
Architecture Diagram
Architecture Diagram
          +----------------+
          |  Client Apps   |
          +-------+--------+
                  |
          +-------v--------+
          |  API Gateway   |
          +-------+--------+
                  |
          +-------v--------+
          |  Transaction   |
          |  Coordinator   |
          +-------+--------+
                  |
          +-------v--------+
          |  Kafka Cluster |
          +-------+--------+
                  |
          +-------v--------+
          | Ledger Service |
          | (Cassandra)    |
          +-------+--------+
                  |
          +-------v--------+
          | Reconciliation |
          |    Service     |
          +----------------+
🧩
Components
API Gateway
Handles client requests, performs authentication, rate limiting, and routes to transaction coordinator.
Why thisNginx with Lua scripting for high throughput and flexible routing with sub-10ms latency.
Why notAWS API Gateway rejected due to vendor lock-in and latency overhead at 1.2M QPS scale.
Transaction Coordinator
Manages distributed transactions ensuring atomic double-entry ledger writes with two-phase commit.
Why thisCustom coordinator using Zookeeper for distributed locking and transaction state management to guarantee atomicity.
Why notUsing traditional RDBMS transactions rejected due to inability to scale beyond 100K TPS and lack of horizontal scaling.
Kafka Cluster
Durable, ordered, and partitioned write-ahead log for ledger entries supporting high throughput and replay.
Why thisKafka supports 1.2M writes/sec with partitioning and replication, enabling event sourcing and auditability.
Why notRabbitMQ rejected due to lower throughput and lack of partitioned log semantics needed for ordering.
Ledger Service (Cassandra)
Stores ledger entries in a double-entry format with partition keys for user wallets, supports fast reads and writes.
Why thisApache Cassandra provides linear horizontal scalability, tunable consistency, and high write throughput for 8.7 PB data.
Why notPostgreSQL rejected due to complex manual sharding and write bottlenecks at 1M+ TPS.
Reconciliation Service
Periodically scans ledger entries to detect inconsistencies, missing entries, and triggers correction workflows.
Why thisBatch processing with Apache Spark on Cassandra snapshots enables scalable reconciliation over petabytes of data.
Why notManual reconciliation rejected due to human error risk and inability to scale to billions of transactions.
🔄
Data Flow
1
Client Apps → API Gateway
Submit wallet transaction request (debit and credit details).
Client initiates transfer with source and destination wallet IDs.
2
API Gateway → Transaction Coordinator
Validate request and initiate distributed transaction.
Coordinator acquires locks on involved wallets to ensure isolation.
3
Transaction Coordinator → Kafka Cluster
Write debit and credit ledger entries as atomic event pair.
Kafka ensures ordered durable log for replay and audit.
4
Kafka Cluster → Ledger Service (Cassandra)
Consume ledger events and persist entries with double-entry consistency.
Cassandra stores entries partitioned by wallet ID for fast access.
5
Ledger Service → Transaction Coordinator
Acknowledge successful commit of both ledger entries.
Coordinator confirms transaction commit to API Gateway for client response.

Practice

(1/5)
1. A high-traffic e-commerce platform expects a sudden surge in user requests immediately after launch. Which component is best suited to pre-populate the cache with frequently accessed product data to avoid cold-start latency?
easy
A. Implement a cache warming service that preloads hot keys into the in-memory cache before launch
B. Use a CDN to cache static assets only, ignoring dynamic product data
C. Rely on lazy loading where cache entries are populated only on first user request
D. Use a write-through cache that updates cache only after database writes occur

Solution

  1. Step 1: Identify cache warming purpose

    Cache warming service proactively loads hot keys to avoid cold cache latency at launch.

  2. Step 2: Eliminate lazy and write-through options

    Lazy loading causes initial latency; write-through updates cache reactively, not proactively.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Preloading hot keys before launch avoids cold cache misses [check]
Hint: Preload hot keys before launch to avoid cold cache misses [OK]
Common Mistakes:
2. A load balancer must detect unhealthy backend servers and reroute traffic without client impact. Which component is primarily responsible for detecting server health status?
easy
A. Health check module that periodically probes backend servers
B. Client-side retry logic to avoid failed servers
C. Load balancer's session persistence cache to track server availability
D. DNS resolver that removes unhealthy servers from DNS responses

Solution

  1. Step 1: Identify health detection responsibility

    The health check module actively probes backend servers to determine their health status.

  2. Step 2: Eliminate other options

    DNS resolver changes are slow and indirect; session persistence caches track sessions, not health; client-side retries do not detect server health.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Health check module probes servers directly for health [check]
Hint: Health checks probe servers directly to detect failures [check]
Common Mistakes:
3. For mobile clients with intermittent connectivity, which message sync strategy is best to minimize data usage while ensuring eventual consistency?
medium
A. Use delta-based sync with version vectors to fetch only changed messages on reconnect
B. Use WebSocket streaming for real-time sync regardless of connectivity
C. Use full message history sync on every reconnect to ensure consistency
D. Use polling every 5 seconds to fetch new messages

Solution

  1. Step 1: Evaluate sync strategies for intermittent mobile connectivity

    WebSocket streaming fails on unstable networks; polling wastes bandwidth; full sync is expensive.

  2. Step 2: Delta-based sync with version vectors minimizes data and ensures eventual consistency

    Only changed messages are fetched, reducing data usage and handling offline periods gracefully.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Delta sync + version vectors -> efficient, consistent mobile sync [check]
Hint: Delta sync with version vectors minimizes mobile data use [OK]
Common Mistakes:
4. Without the graph database's relationship index, what exactly breaks during a shortest path query between two nodes?
medium
A. The query silently returns empty results without any error indication
B. The query falls back to scanning all nodes and edges, causing severe latency spikes
C. The query returns incorrect paths due to stale data in the index
D. The query crashes the database server due to unhandled exceptions

Solution

  1. Step 1: Role of relationship index

    The index enables efficient lookup of edges; without it, traversal cannot proceed correctly.

  2. Step 2: Behavior without index

    Queries relying on the index return empty results silently because no edges are found, not errors or scans.

  3. Final Answer:

    Option A -> Option A

  4. Quick Check:

    Missing index causes silent empty results, not crashes or scans [check]
Hint: Missing index -> silent empty results, no errors or scans [check]
Common Mistakes:
5. At 10x scale, which component in a circuit breaker-enabled microservice architecture is most likely to fail first, and why?
hard
A. The downstream service, because it cannot handle increased request volume despite circuit breaker protection
B. The circuit breaker state store, because centralized state tracking causes contention and latency under high concurrency
C. The load balancer, because it cannot distribute 10x more connections evenly
D. The client-side cache, because it grows too large and causes memory pressure

Solution

  1. Step 1: Analyze scaling impact on components

    Downstream service (A) is protected by circuit breaker; load balancer (C) scales horizontally; client cache (D) is local and less critical.

  2. Step 2: Identify circuit breaker state store bottleneck

    Centralized state store for circuit breaker metrics faces contention and latency at 10x concurrency, causing delays and incorrect breaker states.

  3. Final Answer:

    Option B -> Option B

  4. Quick Check:

    Centralized circuit breaker state store bottlenecks first at scale [check]
Hint: Centralized circuit breaker state store bottlenecks first at scale [OK]
Common Mistakes:
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard