Event-sourced ledger core
Every balance is a replay of its own history, not a cached total.
All Projects
Backend · Ledger & payments
Rebuilding a core ledger that closes the day in minutes
A twenty-year-old batch ledger replaced with an event-sourced platform, cutting end-of-day close from six hours to four minutes.
Start a Project- Client
- Nordhaven
- Industry
- Core banking & ledger infrastructure
- Year
- 2023
- Duration
- 18 weeks
- Role
- Backend engineering + data migration
- Team
- 5 engineers, 1 DBA
- Platform
- Backend
The challenge
The batch job that produced each day's balances couldn't explain how it got there — it summarized the day's activity into a single number and discarded the steps. Every close meant a manual reconciliation pass to reconstruct what the batch had already thrown away, and any discrepancy was chased by hand through print-outs from three other systems.
Approach & solution
Approach
We treated the reconciliation pass itself as the defect, not the numbers it was reconciling. Rather than patch the batch job faster, we modeled the ledger as a stream of events and made every balance a replay of its own history — so there is structurally nothing left to summarize away, and nothing to reconcile after the fact.
Solution
An event-sourced ledger core that recomputes balances by replaying history rather than trusting a cached total, a replayable audit trail regulators can query directly instead of requesting a report, and a live close-time dashboard the finance team watches drop in real time instead of finding out the next morning.
What shipped
The capabilities behind the screens.
Event-sourced ledger core
Every balance is a replay of its own history, not a cached total.
Replayable balances
Reprocessing the full event stream always reaches the same number.
Live close-time dashboard
Finance watches the day's close drop in real time.
Regulator-queryable audit trail
Auditors query the ledger directly instead of requesting a report.
Four-minute close
Down from six hours, with no manual reconciliation step.
Idempotent event replay
Reprocessing a day's events twice never double-counts a balance.
Tech Stack & Architecture
Services, APIs, and business logic running the system end to end.
4 tools · 1 primary
Datastores and pipelines chosen for this engagement's consistency and throughput needs.
3 tools · 1 primary
Deployment, orchestration, and delivery tooling running the platform in production.
3 tools · 1 primary
System architecture
Technical challenges
Replaying years of history without years of compute
A naive replay of the full event log would have made every balance query slower than the batch job it replaced. Periodic snapshots let the ledger replay only the events since the last snapshot, keeping replay time flat as history grows.
Guaranteeing exactly-once event application
A retried write after a network blip could apply the same deposit twice. Every event carries an idempotency key checked at write time, so a retry is a no-op rather than a duplicate.
Migrating live balances without a stop-the-world cutover
The bank couldn't halt transaction processing to migrate. We ran the event-sourced ledger alongside the batch system for a full quarter, comparing balances nightly, before switching the close process over.
How it was built
The stages this engagement ran
01
Brief & Strategy
2 weeks
Traced a month of closes to find where the batch job's summarizing actually lost information.
02
Strategy & Planning
2 weeks
Event schema and snapshot strategy agreed before any migration code was written.
03
UX & UI Design
1 week
The close-time dashboard was the only screen — designed around what finance actually watches.
04
Development
8 weeks
Ledger core and replay engine built alongside a shadow-run harness from day one.
05
QA & Optimization
3 weeks
Ran in parallel with the batch system for a full quarter, diffing balances nightly.
06
Deployment & Support
2 weeks
Cut over close-by-close, oldest accounts first, with the batch job kept warm as a fallback.
Results
What changed, in the numbers.
“For the first time, an auditor's question about a balance is a query, not a research project.”
Marcus Webb · VP Engineering · Nordhaven
Selected screens
Nordhaven, in the product
Related work
Works you may also like.
Technical briefingNot a sales desk