Data & money: build a correct money mover

Build a small wallet/ledger service (any language + a real transactional database) that moves money between accounts correctly under retries and concurrency. It must implement an append-only double-entry ledger, accept client idempotency keys, perform atomic transfers that cannot double-spend or lose updates, and include a reconciliation pass that verifies the books balance — then prove all of it with adversarial tests.

• Model an append-only double-entry ledger: a transfer writes two entries (debit + credit) that sum to zero, entries are immutable (never updated or deleted), and an account balance is derived by summing its entries — not stored as a mutable field. Seed a few accounts with opening-balance entries.
• Implement a transfer(from, to, amount, idempotency_key) operation in a single database transaction: check sufficient funds, append the debit and credit entries, and commit atomically — both legs or neither.
• Add idempotency: persist the idempotency key with the transfer result under a unique constraint, and on a repeated key return the original result without moving money again. Reject a reused key whose parameters differ.
• Defeat the lost update: ensure two concurrent transfers from the same account cannot both succeed past the balance (use an atomic conditional check, SELECT … FOR UPDATE, or a serializable transaction) — and document which mechanism you chose and why.
• Write a reconciliation pass: independently recompute every account balance by summing its entries and assert the global invariant that total debits equal total credits (money is conserved); make it runnable on demand and report any imbalance.
• Adversarial test 1 — retry storm: fire the SAME transfer request N times concurrently (same idempotency key) and assert exactly one set of ledger entries was created and the balance moved once.
• Adversarial test 2 — concurrent debits: fire many concurrent transfers from one account whose total exceeds its balance, and assert the account never goes negative and the books still balance (no lost update, no money created).
• Write a short design note: state your isolation level / locking choice, why the balance is derived rather than stored, and one failure mode reconciliation would catch that the hot path alone would not.

• An append-only ledger where balances are computed by summing immutable entries, with a seed script and a query that prints any account's balance and its entry history.
• A transfer that is atomic (both entries or neither) and idempotent (a repeated key returns the original result with no second movement; a conflicting key is rejected).
• A passing retry-storm test: N concurrent identical requests produce exactly one transfer's worth of entries and a single balance change.
• A passing concurrent-debit test: many over-committed concurrent transfers leave the account non-negative and the global debits = credits invariant intact.
• A reconciliation command that recomputes balances from entries and reports the books as balanced (and would flag an injected imbalance), plus the design note explaining the isolation/locking choice and one failure reconciliation catches.