Same posting load, two fates: a single contended balance row vs. sharded sub-accounts with buffered posting and periodic roll-up
Guided views
Explore this system
Step through curated paths without changing the source diagram.
Beat
Next
ReadyChapter 01 / 01
Guided chapter
Diagram guideExplore this system
Inspecting compiled semantics
E ExportT ThemeS Style0 Reset+ Zoom in- Zoom outEsc Close
Find a node
⌕/
No matching nodes
Semantic passport
Verified source
Authored reach
Route probeChoose a start node
Pick two semantic nodes on the diagram
Choose the source, then the destination. Direction matters.
Semantic lensCompare system roles
Choose up to two semantic kinds. One reveals its real traffic; two compare only direct authored relationships.
Choose a kind to inspect its nodes and touching relationships.
Semantic radar
Building overview
Click nodeDrag to pan
The problem: hot-row contention
• Every posting is an UPDATE of the same balance row
• Row locks serialize concurrent writers into a queue
• Throughput is capped no matter how many app servers you add
The fix: shard the balance
• Split one logical account into N sub-account buckets
• Route each posting to a bucket by hash, so writes spread out
• Contention drops ~N-fold; buckets accept writes in parallel
Buffered posting + roll-up
• Buckets hold buffered partial balances, not the truth on their own
• A periodic roll-up job sums the buckets
• Invariant: logical balance = sum of all sub-accounts
Data-flow diagram • Built with Archify • Create yours ↗ • Hover to trace • R route • Click to focus • +/− zoom • M radar • [/] views • P play story • T theme • E export