Scaling & Performance Benchmarks

Test Environment

Headline Throughput

Measured at 1K accounts. Throughput degrades at larger scales — see tables below.

Account Creation

Each account creation involves: generate customer, store PII, append to slice, register in go-luca ledger (creates account paths), and fund with initial deposit. This is the most expensive operation per-account due to multiple SQL round-trips through go-luca.

Scaling: Near-linear. Throughput drops ~12% from 1K to 10K due to growing ledger size. Each account generates ~8 MB of cumulative allocations (mostly SQL operations in go-luca). The per-account cost is dominated by 3–4 SQL round-trips for ledger registration and initial funding.

End-of-Day Simulation (365 days)

Each simulated day: accrue interest on all accounts (daily_rate = annual_rate / 365), update balances via go-luca, emit transaction log entries. The txLog is cleared each day to bound memory.

Scaling: Sublinear — throughput drops ~40% from 1K to 10K (10.4M vs 17.3M account-days/sec). The per-day cost grows slightly faster than linearly because go-luca SQL queries (GetAccountByID, BalanceAt, RecordMovement) become slower as the ledger table grows. Memory per iteration is constant (161 KB / 36 allocs) since txLog is cleared daily.

Full Year (Create + Simulate)

Combined benchmark: create all accounts then simulate 365 days.

Key insight: Account creation dominates total runtime (~97–99%). Once accounts exist, simulating an entire year is fast. This means the simulation is well-suited for long-running scenarios where you create once and simulate over extended periods.

Extrapolated Scaling

Projections based on observed scaling behaviour. Actual numbers may differ — the sublinear degradation in SQL performance means these are lower bounds for time.

Note: “Cumulative Allocs” is total bytes allocated and freed over the run (from -benchmem), not peak RSS. Go’s GC reclaims most of it. Observed peak RSS for 1K accounts is ~145 MB.

Environment Sizing Guide

Each environment has a natural scale determined by available RAM (for the in-memory SQLite backend) and acceptable wall-clock time for initial creation.

WASM (browser): Limited to browser memory (~2–4 GB). Safe ceiling is ~1K–5K accounts. The demo defaults to 1K for this reason.

Resource Constraints

Bottleneck Analysis

The dominant cost is go-luca’s per-account SQL round-trips, each requiring:

1. GetAccountByID — fetch account details
2. BalanceAt — query closing balance
3. RecordMovement — insert interest movement

That’s 3 SQL operations per account per day for interest accrual alone. Account creation adds further round-trips for ledger registration and initial funding.

Optimisation Paths (not yet implemented)

Sense Checks

• Linear creation: 1.48ms/account at 1K vs 1.68ms at 10K — ~12% degradation is consistent with B-tree index growth in SQLite. Plausible.
• Sublinear simulation: 10x accounts takes 16x as long — consistent with SQL query time growing with table size. The O(n log n) profile matches SQLite B-tree lookup cost increasing as the movements table grows.
• Memory constant per-day: 161 KB / 36 allocs per simulation iteration regardless of account count — confirms txLog clearing works and daily overhead is fixed.
• Creation dominates: 97–99% of total time is account creation. This makes sense: creation does ~4 SQL round-trips per account versus simulation doing 3 per account per day, but creation also involves RNG, PII storage, and slice management.
• Cumulative vs peak: 8.1 GB cumulative allocs for 10K accounts, but peak RSS is far lower thanks to GC. The B/op metric from -benchmem is total allocated, not retained.

Running Benchmarks

All benchmarks are defined in cmd/demo/benchmark_test.go and invoked via Taskfile:

Custom metrics reported: accounts/sec, account-days/sec, eod-accounts/sec, create-ms, sim-ms.