Aequitas Ledger
A ledger that can't lose a cent, settling 268k transfers a second on a single machine.
268k+ TPS
- 268,400+ TPS verified on synthetic transactional load benchmarks
- Sub-millisecond p99 latency with deterministic group commit
- Strict double-entry invariants with zero-drift accounting safety
# What it is
Aequitas Ledger is a mission-critical double-entry accounting engine written in Go. Built for financial platforms that require absolute mathematical correctness, zero balance drift, and ultra-high throughput without distributed consensus overhead on the critical write path.
# Why it exists
Traditional relational databases degrade under high concurrent double-entry updates due to row locks, latch contention, and async write-ahead log flushes that risk data loss during power failure.
# How it works
A single lock-free writer loop applies balance mutations from an in-memory journal; every accepted operation lands in a binary O_DIRECT write-ahead log with group-commit fsync windows, and crash recovery replays WAL checkpoints. Debit/credit conservation is enforced as a runtime invariant inside the write path — not as a post-hoc audit. The design deliberately trades horizontal scale for deterministic single-node throughput, the same trade TigerBeetle makes.
# Decisions worth explaining
- 01
Single-writer event loop over multi-threaded concurrency
Removing lock contention entirely is the only way to reach deterministic p99 under 300k TPS; all account state lives behind one serial writer so invariants never contend.
- 02
O_DIRECT group-commit WAL bypassing OS page cache
Buffered WALs make fsync latency nondeterministic and risk acknowledged-write loss on power failure; O_DIRECT makes commit durability explicit and batchable.
- 03
Zero-panic gates with double-entry invariants in the write path
Borrowed from TigerBeetle: debit/credit conservation is checked before a mutation commits, so balance drift is structurally impossible rather than caught in reconciliation.
# Details
- Single-writer lock-free event loop processing account balance updates in memory
- O_DIRECT group-commit Write-Ahead Log (WAL) bypassing OS page caches for deterministic fsync
- Strict balance debit-credit balance conservation invariants enforced at runtime
- Crash-resilient recovery from binary WAL checkpoints with zero-panic execution gates
# Built with
Go · WAL · gRPC · Lock-Free Concurrency · O_DIRECT · Financial Systems