--- title: "Why Optimistic Locking in Ledgers Isn’t Always a Good Idea" url: https://daily.dev/posts/why-optimistic-locking-in-ledgers-isn-t-always-a-good-idea-o8cl8lh1z source_url: https://news.alvaroduran.com/p/why-optimistic-locking-in-ledgers type: article source: "The PayEng Playbook" published: 2026-08-19T10:33:11.541Z updated: 2026-08-19T10:33:37.153Z tags: ["database", "fintech"] reading_time: 6 upvotes: 1 comments: 0 language: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Why Optimistic Locking in Ledgers Isn’t Always a Good Idea **[The PayEng Playbook](https://daily.dev/sources/alvaroduran)** · 6 min read · 1 upvotes · 0 comments ## Summary Ledger systems must be correct in two senses: producing accurate financial statements and gatekeeping which transactions are allowed in. Version locking (tracking an account_version on entries, distinct from same-table optimistic locking) is a common way payments engineers prevent double-spend race conditions, but it causes thread contention on frequently updated accounts such as pools of funds. Accounts that don't need real-time balance checks are better served by end-of-day balance snapshots rather than forcing every write through strict version locking, and balance should not simply live as a column on the Account table since its use case determines where it should be stored. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Why does version locking on a ledger account cause high latency for frequently updated accounts? Version locking rejects any transaction whose account version has changed since it was read, forcing retries. Accounts updated very often, such as pooled funds accounts that aggregate many deposits and withdrawals, experience heavy thread contention because most concurrent writes get rejected and must retry, driving up overall latency even though these accounts rarely need strict real-time balance checks. _Engineers weighing locking strategies for high-traffic ledger accounts can track this kind of design trade-off on daily.dev._ ### What is the difference between standard optimistic locking and the account-version locking used in ledger systems? Standard optimistic locking, like the version column pattern in ActiveRecord, is scoped within the same table being updated. Account-version locking used in ledgers instead stores the version in a separate Entries table via an account_version column, which references the Account's version at the time each entry was recorded, preserving monotonic ordering of entries across a different table than the one being versioned. _Anyone architecting ledger data models can find these distinctions on daily.dev before picking a locking scheme._ ### Should account balance be stored as a column on the Account table in a ledger system? Not necessarily; whether balance belongs on the Account table depends on whether it is used for real-time integrity checks or for reporting. Accounts needing real-time checks cannot risk stale or inconsistent balance data, while accounts functioning as pools of funds can safely use an end-of-day balance stored directly on the Account table without risking data integrity issues. _Developers deciding how to model balances in a ledger schema can follow this kind of guidance on daily.dev._ ## Similar posts on daily.dev - [Assume that Manual Work in a Ledger Is Impossible](https://daily.dev/posts/assume-that-manual-work-in-a-ledger-is-impossible-d3lwzbjww) · The PayEng Playbook · 0 upvotes · 0 comments - [Optimistic Locking vs Pessimistic Locking](https://daily.dev/posts/optimistic-locking-vs-pessimistic-locking-tnez3fjrn) · Towards Dev · 25 upvotes · 0 comments --- Tags: [#database](https://daily.dev/tags/database), [#fintech](https://daily.dev/tags/fintech) [View this post on daily.dev](https://daily.dev/posts/why-optimistic-locking-in-ledgers-isn-t-always-a-good-idea-o8cl8lh1z)