Design a High-Throughput Core Banking Ledger & Merchant Settlement Engine
Imagine you are building the core ledger and transaction engine for a global payment processor powering major e-commerce platforms. Your platform handles millions of concurrent authorization holds, captures, refunds, and merchant account settlements. During major shopping events, single high-volume merchant accounts experience tens of thousands of concurrent payment writes per second. You need to design an immutable, audit-compliant double-entry ledger that guarantees zero balance drift, strict idempotency, sub-50ms authorization holds, and high availability without choking on hot merchant accounts.
- Support atomic two-phase payment operations: place authorization hold, capture payment, void hold, and issue full or partial refunds.
- Maintain an immutable double-entry ledger where every entry balances (sum of debits equals sum of credits) across asset, liability, and revenue accounts.
- Provide exact point-in-time account balance queries and transaction audit histories.
- Enforce strict end-to-end idempotency for all payment requests using client-provided keys.
- Latency: Authorization hold placement p99 latency < 50ms; asynchronous capture/settlement processing p99 < 500ms.
- Consistency: Strict serializability for balance updates; absolute zero balance drift or uncollected overdrafts.
- Availability: 99.999% uptime for authorization holds and balance inquiries.
- Durability: Zero data loss (RPO = 0) for committed ledger entries across multi-region deployments.
Global Peak Volume: 50,000 transaction requests per second globally. Hot Account Volume: Up to 5,000 concurrent writes/sec hitting a single enterprise merchant account during flash sales. Data Volume: 500 million ledger events daily with 10 years of immutable retention.
- High-level architecture diagram detailing the API gateway, authorization engine, ledger writer, partition strategy, and persistence storage layer.
- Data model for ledger accounts, journal entries, postings, and idempotency state tracking.
- Detailed design for resolving hot-account write contention without database row-locking bottlenecks.
- Failure recovery workflow for node/region crashes during mid-flight multi-phase settlements.
Evaluates whether the candidate designs an immutable schema separating journal entries (transaction headers) from individual debit/credit postings, enforcing strict debit-credit zero-sum balance constraints per transaction and preventing direct UPDATE/DELETE operations on historical entries.
Evaluates the candidate's strategy to bypass single-row database lock bottlenecks for high-volume accounts (e.g., using bucketed shadow balance accounts, append-only event-sourced streams, or optimistic concurrency control with batch background aggregation).
Evaluates how the system handles duplicate requests, network retries, and multi-phase payment lifecycles (Authorization -> Hold -> Capture/Void) using persistent idempotency keys and explicit state machine transitions.
Evaluates the architecture for cross-region replication, quorum-based write consensus (e.g., Spanner, CockroachDB, or Raft-backed log replication), and RPO=0 disaster recovery during region failure.
Evaluates the design for background snapshotting, continuous ledger reconciliation, detection of balance anomalies, and cryptographic/hash-chain verification for tamper-evident auditing.
Every functional requirement in the brief is visibly served by something on the board, and the non-functional targets are addressed rather than ignored.
Components are labelled, data flows are drawn as connections between them, and the direction of each flow is unambiguous.
Follow-up: How would you extend this system to support multi-currency cross-border transfers where exchange rates fluctuate continuously, requiring atomic FX rate locks during authorization holds and cross-currency settlement matching?
The ledger must strictly enforce double-entry bookkeeping (debits equal credits for every transaction entry). Balance reads and hold placements must remain sub-50ms p99 even during extreme hot-key access on single merchant accounts. No money can be created or destroyed due to race conditions or partial failures. System must survive single-AZ and full region outages with zero data loss (RPO=0) and no corrupted ledger entries.
- Views
- 25