Question 1

How do you model a balance ledger to prevent double-spending in a digital wallet?

Accepted Answer

Use an append-only ledger table where each row is an immutable credit or debit entry with a transaction ID, account ID, amount, and timestamp. Never store a mutable 'balance' column directly — derive the balance via SUM of entries. To prevent double-spending, wrap fund transfers in a serializable database transaction with a SELECT FOR UPDATE on the account row, or use optimistic concurrency with a version counter. For high-throughput systems, shard the ledger by account ID and use idempotency keys on the API layer so retried requests don't produce duplicate entries.

Question 2

What is the safest way to implement fund transfers between two wallet accounts atomically?

Accepted Answer

A fund transfer must debit one account and credit another as a single atomic unit. The canonical approach is a two-row ledger insert inside one database transaction: insert a debit entry for the source and a credit entry for the destination, then commit. To avoid deadlocks when two concurrent transfers touch the same pair of accounts in opposite order, always acquire row locks in a canonical account-ID order (e.g., lower ID first). For distributed wallets spanning multiple shards, use a saga pattern with compensating transactions, or a two-phase commit coordinated by a trusted transfer service that records a PENDING state before applying debits and credits.

Question 3

How would you design the reconciliation process for a wallet service that processes millions of transactions per day?

Accepted Answer

Reconciliation compares the internal ledger against external settlement records (bank, card network, or blockchain). Run a nightly batch job that reads all settled external events for a time window, joins them against internal ledger entries by external transaction ID, and flags mismatches — amounts differ, an entry is in one system but not the other, or settlement is delayed. Store reconciliation results in a separate audit table with status (MATCHED, UNMATCHED, PENDING). For real-time alerting, compute a running checksum or Merkle tree over ledger entries so any tampering is immediately detectable. Expose a dashboard showing unmatched item count, total unmatched value, and aging buckets.

Question 4

How do you handle currency conversion and floating-point precision in a multi-currency wallet?

Accepted Answer

Never use IEEE 754 floating-point types (float, double) for monetary amounts. Store all amounts as integers in the smallest currency unit (cents for USD, paise for INR) alongside a currency code. For conversion, fetch exchange rates from a rate service and store the rate used at transaction time in the ledger entry for auditability — rates must never be reconstructed retroactively. Apply rounding according to each currency's ISO 4217 exponent using banker's rounding (round-half-to-even) to minimize systematic bias. Conversion gains and losses should be booked as separate ledger entries to a dedicated FX P&L account so the books always balance.

Digital Wallet Service Low-Level Design: Balance Ledger, Fund Transfer, and Reconciliation

Double-Entry Ledger

Transaction Schema

Atomic Fund Transfer

Balance Calculation and Denormalization

Balance Cache

Idempotency

Transaction Limits and Fraud Checks

Currency Handling

Wallet Hierarchy

Withdrawal to Bank

Daily Reconciliation