Back to portfolio

Chapter 01 - Fintech backend engineering

Arus - Double-Entry Ledger

Live in production

A production Go ledger proving money correctness with 600 TPS max clean sustained throughput, explicit row locks, transactional outbox delivery, and Family Finance shadow-write validation.

Arus ledger architectureAPI requests pass through a posting engine into PostgreSQL and an outbox relay that publishes to Kafka or Pub/Sub consumers.post entrybalanced transactionentry.committedpoll batchpublishdeliverHTTP APIAPI-key ledger scopePosting engineIdempotency + ordered locksPostgreSQLEntries, postings, balancesOutboxSame DB transactionRelayFOR UPDATE SKIP LOCKEDKafka / Pub/SubLocal Redpanda, cloud Pub/SubConsumersDedupe by event_idInvariant: the journal and outbox row commit together; consumers dedupe by event_id after Kafka or Pub/Sub delivery.
600 TPS

max clean sustained throughput

p99 229 ms

rounded from 228.73 ms at 600 TPS

0 drift

trial balance and shadow-write consistency

~$17.50/mo

low-traffic Cloud Run + Cloud SQL footprint

Why a ledger

A ledger before payment orchestration

Arus isolates the money-correctness core first: balanced entries, idempotent mutations, scoped API keys, immutable postings, and trial-balance verification before higher-level payment flows are added.

Source: ledger/docs/product-requirements/2026-06-11-v01-ledger-v1-prd.md

Why a ledger

Designed for a real first consumer

Family Finance shadow-writes transaction create, update, and delete events into Arus without changing user balances, then reports zero drift after the outbox drains.

Source: family-finance/docs/docs/runbooks/2026-06-11-v01-ledger-shadow-write-walkthrough.md

Architecture

Posting engine first, broker second.

The API writes entries through one posting engine transaction. PostgreSQL holds the journal, materialized balances, idempotency claims, and outbox rows; a relay publishes through Kafka locally or Pub/Sub in Cloud Run.

Arus ledger architectureAPI requests pass through a posting engine into PostgreSQL and an outbox relay that publishes to Kafka or Pub/Sub consumers.post entrybalanced transactionentry.committedpoll batchpublishdeliverHTTP APIAPI-key ledger scopePosting engineIdempotency + ordered locksPostgreSQLEntries, postings, balancesOutboxSame DB transactionRelayFOR UPDATE SKIP LOCKEDKafka / Pub/SubLocal Redpanda, cloud Pub/SubConsumersDedupe by event_idInvariant: the journal and outbox row commit together; consumers dedupe by event_id after Kafka or Pub/Sub delivery.

ADR

Go over Spring

Go keeps the locking, idempotency, and SQL choices visible in the diff while matching the Family Finance backend and Cloud Run deployment path.

Source: ledger/docs/adr/2026-06-11-v01-adr-001-go-over-spring.md

ADR

Pluggable outbox transport

Correctness lives in the transactional outbox, so Kafka can prove local broker semantics while Pub/Sub keeps the cloud deployment serverless and inexpensive.

Source: ledger/docs/adr/2026-06-11-v01-adr-002-outbox-pluggable-transport.md

ADR

Ordered locks over SERIALIZABLE

READ COMMITTED plus deterministic account-balance row locks blocks overdraft races without a broad serializable retry loop.

Source: ledger/docs/adr/2026-06-11-v01-adr-003-locking-and-balance-strategy.md

Correctness evidence

The release gates attack the failure modes.

Race storms, property tests, append-only triggers, cross-ledger isolation tests, and relay chaos tests all protect the path where financial systems usually fail.

Race storms

Concurrent idempotency and overdraft storms are release gates under go test -race; zero balance drift is expected under contention.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-m1-walkthrough.md

Property tests

Rapid balanced-entry tests keep the trial balance at net zero across generated posting sequences.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-m1-walkthrough.md

Relay chaos test

A simulated relay crash after partial publish rolls back the batch and the next relay run republishes without event loss.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-m2-walkthrough.md

Append-only enforcement

Entries and postings reject UPDATE and DELETE through database triggers; corrections use reversal entries.

Source: ledger/docs/system-analysis/2026-06-11-v01-ledger-threat-model-sa.md

IDOR-proof key-scoped auth

The effective ledger_id is derived from the API key, foreign-ledger objects return 404, and read-only keys cannot mutate.

Source: ledger/docs/system-analysis/2026-06-11-v01-ledger-threat-model-sa.md

Load evidence

Publish the ceiling, including the failed bracket.

The 600 TPS run is the sustained result. The 800 TPS target was deliberately published as not sustained because k6 dropped iterations even though the trial balance stayed zero.

TargetObserved req/sp50 msp99 msFailed rateDroppedStatus
600599.003.04228.730.00000Sustained

Max clean sustained target; trial balance net 0.

800770.60358.781038.510.000029Not sustained

Not sustained at target; 29 dropped iterations, trial balance still net 0.

Production

Cloud Run deployment with transparent cost.

The live footprint is Cloud Run, Cloud SQL PostgreSQL, Pub/Sub, Secret Manager, and Cloud Scheduler, with relay and daily close as scheduled jobs.

Cloud stack

Production runs on Cloud Run API, Cloud SQL PostgreSQL, Pub/Sub, Secret Manager, and Cloud Scheduler.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-cloud-run-deploy-walkthrough.md

Cost transparency

Expected low-traffic monthly cost is approximately $17.50, dominated by the smallest viable Cloud SQL footprint.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-cloud-run-deploy-walkthrough.md

Scheduled relay and close

The deployment creates scheduled Cloud Run jobs for outbox relay and daily close snapshots.

Source: ledger/docs/runbooks/2026-06-11-v01-ledger-cloud-run-deploy-runbook.md

Same-day reviewed milestones

The 2026-06-11 PRD, three milestone walkthroughs, hardening, deployment, and shadow-write docs record the PRD-to-production path.

Source: ledger/docs/INDEX.md

Integration

Family Finance validates the consumer story.

The first consumer uses shadow writes, reversal-based updates, and a consistency report so the portfolio story is backed by an end-to-end system, not a standalone demo.

4/4 shadow events drained

The Family Finance demo enqueued create, update, income create, and delete events; the drain processed 4/4 successfully.

Source: family-finance/docs/docs/runbooks/2026-06-11-v01-ledger-shadow-write-walkthrough.md

Reversal-based updates

Update posts reverse the prior successful ledger entry before posting the next version; delete performs reversal only.

Source: family-finance/docs/docs/system-analysis/2026-06-11-v01-ledger-shadow-write-sa.md

zero_drift report

The consistency report returned zero_drift with expected cash balance 20000 matching ledger cash balance 20000.

Source: family-finance/docs/docs/runbooks/2026-06-11-v01-ledger-shadow-write-walkthrough.md

Roadmap

Shipped and planned work stay separated.

Phase 3 reconciliation has shipped as Selaras, Phase 4 payment orchestration has shipped as Alur, and Phase 5 dispute adjudication has shipped as Banding. Family Finance money storage hardening remains a consumer-side track.

Phase 1 hardening

Family Finance integer-minor-units migration

Family Finance still stores money as float64; Arus is int64 minor units, so the durable integration path starts by removing float money from the consumer.

Source: family-finance/docs/docs/runbooks/2026-06-11-v01-ledger-shadow-write-walkthrough.md

Phase 4 shipped

Alur payment orchestration

Alur now models authorize-to-capture payment state transitions on top of the verified ledger core with a chaos PSP gate and exactly-once booking.

Read Alur case studySource: family-finance/docs/docs/system-analysis/2026-06-12-v01-alur-case-study-evidence-sa.md

Phase 5 shipped

Banding dispute adjudication

Banding now adjudicates Alur captures through a durable deadline scheduler, deterministic network events, and exactly-once Arus dispute writebacks.

Read Banding case studySource: family-finance/docs/docs/system-analysis/2026-06-13-v01-banding-case-study-evidence-sa.md

Phase 3 shipped

Selaras settlement reconciliation

Selaras now closes the Arus v1 control loop with deterministic matching, five break classes, balanced reports, and a fixture-backed demo.

Read Selaras case studySource: family-finance/docs/docs/system-analysis/2026-06-12-v01-selaras-case-study-evidence-sa.md

Evidence trail

Claims are limited to the approved source documents.

  • PRD: Ledger v1
    ledger/docs/product-requirements/2026-06-11-v01-ledger-v1-prd.md
  • System Analysis: Ledger v1
    ledger/docs/system-analysis/2026-06-11-v01-ledger-v1-sa.md
  • Threat Model: Ledger v1
    ledger/docs/system-analysis/2026-06-11-v01-ledger-threat-model-sa.md
  • ADR-001: Go over Spring Boot
    ledger/docs/adr/2026-06-11-v01-adr-001-go-over-spring.md
  • ADR-002: Transactional Outbox with Pluggable Transport
    ledger/docs/adr/2026-06-11-v01-adr-002-outbox-pluggable-transport.md
  • ADR-003: Ordered Row Locks, Materialized Balances, No Event Sourcing
    ledger/docs/adr/2026-06-11-v01-adr-003-locking-and-balance-strategy.md
  • Walkthrough: M1 Posting Engine
    ledger/docs/runbooks/2026-06-11-v01-ledger-m1-walkthrough.md
  • Walkthrough: M2 Balances, Outbox, Events
    ledger/docs/runbooks/2026-06-11-v01-ledger-m2-walkthrough.md
  • Walkthrough: M3 Hardening and Cloud Prep
    ledger/docs/runbooks/2026-06-11-v01-ledger-m3-walkthrough.md
  • M3 k6 Baseline Summary
    ledger/docs/load-tests/2026-06-11-v01-ledger-m3-load-test.md
  • Walkthrough: Cloud Run Deploy
    ledger/docs/runbooks/2026-06-11-v01-ledger-cloud-run-deploy-walkthrough.md
  • System Analysis: Ledger Shadow-Write Integration
    family-finance/docs/docs/system-analysis/2026-06-11-v01-ledger-shadow-write-sa.md
  • Walkthrough: Ledger Shadow-Write Integration
    family-finance/docs/docs/runbooks/2026-06-11-v01-ledger-shadow-write-walkthrough.md