The worker crashes, and the same payment event arrives again
One transaction writes the entry and every leg. The event ID is a unique key, so the retry gets the same entry back.
A bug booked 10% commission, not 6%
Bad: Edit the entry
No trace of who changed it; sent statements now disagree.
Good: Reverse, then re-post
A mirror entry cancels it, a new one is right. The original stays.
Two ₹800 spends hit a ₹1,000 wallet at once
Check, then write lets both through. Put the check inside the write, and the second spend waits, re-checks ₹200 and is refused.
5,200
postings a second on one account at peak
Every payment credits commission revenue. A row lock held 2.5 ms caps one row at 400 updates a second, 13 times short.
Commission revenue has no limit. Why lock it 5,200 times a second?
The trick
Lock only accounts with rules, like wallets. The rest just insert, and a job folds them into the balance every second.
You send ₹500 to a friend on another shard
No lock spans both. Two local entries meet in a pair of clearing accounts that must net to zero; non-zero means a stuck transfer.
Prove nothing was lost or changed
- All postings per currency sum to zero, nightly
- Clearing accounts return to zero on time
- Every producer event has a ledger entry
- Hash-chain every shard, seal signed 30-minute windows
Remember
Post balanced entries exactly once and never edit them. Lock only accounts with rules; fold the rest. Prove it with sums that must be zero.