//www.martinrichards.me/tags/financial-systems/ Recent content in Financial Systems on Martin C. Richards Hugo en Sun, 18 Jan 2026 12:00:00 +0200 //www.martinrichards.me/post/ledger_p2_scaling_double_entry_ledger_massive_psp/ Sun, 18 Jan 2026 12:00:00 +0200 //www.martinrichards.me/post/ledger_p2_scaling_double_entry_ledger_massive_psp/ <h1 id="scaling-a-double-entry-ledger-for-a-massive-psp">Scaling a Double-Entry Ledger for a Massive PSP</h1> <p>In <a href="//www.martinrichards.me/post/ledger_p1_optimistic_locking_real_time_ledger/">Part 1</a>, we built a real-time double-entry ledger using optimistic locking. We benchmarked it and found it handles <em>160-440 req/sec</em> depending on contention, with zero errors and stable tail latencies. But benchmarks on localhost are one thing. <strong>Production at PSP scale is another.</strong></p> <p>This post answers the question: <em>Can this architecture handle a massive Payment Service Provider processing 10 million transactions per day?</em> Spoiler: <strong>Yes, but only if you get the account hierarchy right.</strong></p> //www.martinrichards.me/post/ledger_p1_optimistic_locking_real_time_ledger/ Sat, 17 Jan 2026 10:00:00 +0200 //www.martinrichards.me/post/ledger_p1_optimistic_locking_real_time_ledger/ <h1 id="optimistic-locking-in-a-double-entry-ledger">Optimistic Locking in a Double-Entry Ledger</h1> <p>Ledgers are a deceptively simple problem to tackle. At a certain scale, leveraging a simple <code>SELECT FOR UPDATE</code> works perfectly well—wrap everything in a transaction, and move on.</p> <p>But the moment you need concurrent writes to the same accounts, hundreds of transactions per second, and real-time balance consistency—everything changes. Suddenly, pessimistic locking becomes your bottleneck. Every read blocks, every write queues, and your payment API starts timing out under load.</p>