Back to HomepageCase Studies // Post-Mortems v2.4
case studies / post-mortems

Production Case Studies

Unfiltered dissections of production systems: the messy initial problems, architectural decisions and trade-offs, and quantified performance outcomes.

Distributed Ledger & Double-Entry Accounting3-Week Sprint

LedgerFlow — Real-Time Idempotent Financial Reconciliation

Engineered an immutable, double-entry financial ledger that eliminated balance race conditions across 450,000 daily transactions with zero overdraft discrepancies.

Client: Fintech Payment Gateway
QUANTIFIED ARCHITECTURAL OUTCOMES:
Balance Discrepancies
0.38% of transactions0.00%
100% mathematical integrity
Settlement ACK Latency
4,200ms batch delay85ms
49x faster settlement
Ingestion Throughput
120 tx/s1,250 tx/s
10.4x throughput scale
The Architecture Bottleneck (Before):

Asynchronous payment settlement webhooks and mobile retry taps created phantom double-debit entries and balance overdraft race conditions during peak flash sales. The legacy system relied on simple UPDATE balance = balance - amount queries that failed under concurrent load.

The Engineering Solution (After):

Enforced strict double-entry accounting with PostgreSQL immutable ledger rows, serializable transaction isolation, Redis distributed mutex locks (Redlock), and database-level atomic balance check constraints.

TECHNICAL DECISIONS & ENGINEERING TRADE-OFFS:
Decision 01: Immutable Append-Only Ledger vs Mutable Balances
Rationale: Rather than updating an account balance row directly, every transaction inserts two balanced ledger entries (Debit and Credit). Current balances are computed from materialized balance snapshots plus recent delta rows.
Decision 02: Serializable Transaction Isolation
Rationale: Enforced SET TRANSACTION ISOLATION LEVEL SERIALIZABLE during wallet mutations. Any overlapping concurrent transaction attempting to withdraw from the same wallet triggers an immediate clean abort and retry.
Decision 03: Redis Distributed Mutex (Redlock)
Rationale: Serializes concurrent checkout requests on the same user account before touching the database, eliminating 99% of transaction conflict aborts at the cache layer.
VERIFIED ARCHITECTURAL HIGHLIGHTS:
Immutable double-entry ledger with debit/credit balance constraint
Serializable PostgreSQL isolation (SET TRANSACTION ISOLATION LEVEL SERIALIZABLE)
Redlock distributed mutex for atomic wallet balance mutations
Automated end-of-day reconciliation worker with anomaly alerting
PRODUCTION OUTCOMES

Have a similar system to design or fix?

We turn sluggish query bottlenecks, dropped webhooks, and manual spreadsheets into rock-solid production software.

Scope Sprint →Book Discovery Chat ↗