F-01
Double-entry domain model
Invariants encoded directly in Go types: an unbalanced transaction won't compile a path to disk. Validate() runs before anything touches Postgres.
The Ledger Book is out.
Get the book
open source, MIT, Go 1.26
A production-grade payment ledger in Go.
Double-entry accounting with invariants that are impossible to violate. Built in the open over 14 weeks: atomic posting, idempotency, an immutable audit log, and one trace from HTTP to SQL.
internal/domain/transaction.go
// Validate enforces the balance invariant:
// postings must sum to exactly zero.
func (t *Transaction) Validate() error {
if len(t.Postings) < 2 {
return ErrTooFewPostings
}
var sum int64
for _, p := range t.Postings {
sum += p.Amount // signed minor units
}
if sum != 0 {
return ErrUnbalanced
}
return nil
}14 / 14
weeks shipped: the full public roadmap, complete
27 ADRs
one architecture decision record per significant decision
race + lint
tests run with the race detector, lint green in CI
live on push
every push to main deploys to production via CI/CD
01 · guarantees
Correctness first, everything else second.
Six properties a payment ledger must have, each one shipped, tested, and documented in its own build-log post.
F-02
Atomic, concurrency-safe posting
SERIALIZABLE isolation plus ordered row locks, stress-tested under heavy contention. Concurrent posts either fully apply or fully retry.
F-03
Idempotency keys
An Idempotency-Key makes a retry safe: the same key returns the original transaction and never moves money twice.
F-04
Tamper-evident audit log
Append-only, written in the same transaction as the posting, and hash-chained row to row. UPDATE and DELETE are refused by a Postgres trigger, and a verify call recomputes the whole chain to prove nothing was altered.
F-05
REST + gRPC
Two front doors over one shared domain core, so the protocols cannot drift. Same rules, same errors, same guarantees.
F-06
Full observability
One OpenTelemetry trace from HTTP to SQL, the same trace_id in every log line, RED metrics beside the native ones. No amounts ever leave the process.
02 · the plan
Fourteen weeks, in public, all shipped.
The roadmap was published before week one. Every week ships code, a blog post, and the decision records behind it.
wk 01Scaffolding repo, module layout, tooling, hello ledger
wk 02Domain model double-entry accounting in Go types
wk 03Postgres schema migrations and the repository layer
wk 04Atomic posting SERIALIZABLE isolation under concurrency
wk 05REST API chi, validation, OpenAPI
wk 06Idempotency + audit safe retries, immutable audit log
wk 07gRPC layer over the shared domain core
wk 08Observability OpenTelemetry traces, logs, metrics
wk 09Testing unit, property, chaos, load
wk 10Docker + deploy distroless images, live to production
wk 11Multi-currency + FX per-currency invariant, live admin rates, USD-hub conversion
wk 12Nested accounts + reporting rolled-up balances, trial balance
wk 13Approvals + event stream threshold gate, lifecycle events on the audit chain
wk 14Webhooks + launch signed delivery, SSRF-guarded, and the retrospective
all 14 weeks shipped
one ADR per significant decision (27 in all)
go test -race + lint green in CI
live deploy on every push to main
03 · tools
A boring stack, chosen on purpose.
Every dependency earned its place, and each choice has an ADR explaining the trade-offs.
Go
chi + huma
pgx + sqlc
goose
Postgres
gRPC / buf
OpenTelemetry
Prometheus
Docker
Ansible
VPS
GitHub Actions
04 · the record
Every week, written down.
A 14-week build, documented post by post.
The design decisions, the dead ends, and the reasoning behind every invariant, published the week each one ships. Not a tutorial polished after the fact: the real build, in order, with the trade-offs still visible.
Read the series →14 / 14
weeks shipped
27
architecture decisions recorded
05 · the book
The whole build.
Plus the interview.
The 14-week build, every ADR, and the senior-engineer interview questions this project would put you through, in one volume. Free.
Want it in print? Sign interest, Bangladesh only.06 · the builder
Built by Sohag Hasan.
A Tech Lead and Solutions Architect with 8+ years shipping production software across fintech, hospitality, and logistics (Bangladesh, Malaysia, Luxembourg), currently at Moby Money. go-ledger is me going deep on Go and payment infrastructure in public, from an empty repo to a live deploy. Open to fintech leadership, advisory, and interesting infrastructure work.
- role
- Tech Lead, Solutions Architect
- currently
- Moby Money
- experience
- 8+ years, production systems
- base
- Dhaka, Bangladesh (GMT+6)
- remote
- yes, open to it
- open to
- fintech lead, advisory, infra