SysPad › Examples › Digital wallet
Digital wallet
Balance-changing operations write straight to an ACID double-entry ledger DB, which then updates a balance cache and appends to transaction history - reads are cache-fast, writes are deliberately not.
A relational, transactional ledger as the source of truth, with a cache serving only the read-heavy balance-check path.
- Throughput: 6,000 req/sec
- First to saturate: Ledger DB (double-entry)
- Estimated cost: $7,205/mo
How it works
- Balance Cache
- Serves the read-heavy balance-check path: 95% of checks answer from here. It is a downstream copy, never the source of truth - a transfer updates it write-through after the ledger commits.
- Ledger DB (double-entry)
- The ACID source of truth: every balance-changing operation is a double-entry transaction here. Writes are deliberately not cache-fast - correctness beats latency on the money path. The superposition centre, taking cache misses (read) and every transfer (write).
- Transaction History
- The append-only statement trail, written off the hot path after the ledger commits - a transfer confirms without waiting on the history write.
Request flows
Check balance
- Client
- Load Balancer
- Wallet Service
- Balance Cache
- Ledger DB (double-entry)
Transfer funds
- Client
- Load Balancer
- Wallet Service
- Ledger DB (double-entry)
- Balance Cache
- Transaction History