A double-entry core that never loses a cent
Built a strongly-consistent double-entry ledger as a single deployable service on PostgreSQL — every posting committed inside one serializable transaction, with an append-only audit log and a read replica, certified to balance under any failure.
- Monolith
- PostgreSQL
- ACID
- Double-entry
- 9k tx/s
- Throughput
- 11 ms
- p99 write
- provably 0
- Balance drift
Schema migrations run as a gated step before each deploy; the service ships as one immutable image, promoted dev → staging → prod behind a manual approval. Blue/green keeps the ledger answering through the cutover, and a rollback is the previous image.
Ledger had chased elasticity. The payments core had been spread across a sharded, eventually-consistent store on the theory that scale demands a distributed system — and the theory cost them correctness. Cross-shard postings settled out of order, retries occasionally double-posted, and no one could give an auditor a straight answer to the only question that matters: are we certain the books balance? Month-end close took a team of people three days of manual reconciliation.
We made the unfashionable call: collapse the system back into one focused, strongly-consistent service and let a real transactional database do the hard part. When correctness and transactional integrity beat elasticity, the right answer is a monolith on a serious relational core — not a distributed rewrite. The service is a single deployable on ECS Fargate behind an ALB, writing to PostgreSQL on RDS Multi-AZ. Every posting — the matched debits and credits, the balance assertion, the idempotency check — happens inside one SERIALIZABLE transaction, so a double-entry invariant either commits whole or not at all; there is no window in which the books can be half-written. A client-supplied idempotency key carries a unique constraint, making a replayed request a guaranteed no-op rather than a second post. The journal is append-only — entries are never updated or deleted — and a streaming read replica serves reporting and month-end queries without ever touching the write path. We backed it with a property-based suite that throws thousands of randomised, interleaved, partially-failed transactions at the service and asserts the books balance after every single one.
The ledger sustains nine thousand transactions a second at an eleven-millisecond p99 — evidence that a well-built monolith on the right database is not the bottleneck the distributed rewrite assumed it would be. Double-posting is structurally impossible: the serializable transaction and the unique idempotency key leave no room for it. Month-end close is a read against the replica, not a project. Most importantly, correctness is demonstrable rather than hoped-for: balance drift is provably zero, and the append-only journal gives auditors a complete, tamper-evident trail they can replay themselves.
Let’s write the next system into being
Tell us what you’re building. We’ll reply within two business days with a frank read on scope, shape, and whether we’re the right studio for it.