Performance & Scalability

Test date: 28 March 2025 · Duration: 60 minutes continuous · Driver: industry-standard load-testing tool on a laptop over 1 Gbps

This is a small configuration — no failover, no read replicas, no additional API nodes. Production deployments on dedicated hardware significantly exceed these results.

The chart shows 5-minute throughput bars across the full 60-minute test. After a brief ramp-up (first ~15 minutes) the system reached a stable steady state at 466.9 transactions per second and held it — no degradation, no errors, no manual intervention.

All 1,680,964 transactions completed successfully — zero errors in 60 minutes.

Sustained matters more than peak. A burst figure tells you what a system can do for a moment; an hour at steady state tells you what it will do on your busiest day.

The 466.9 TPS figure represents complete double-entry transactions. Each one writes a transaction header, multiple debit/credit detail rows (around 3 on average), a running-balance record and an audit entry — which is why the run produced 5,012,190 detail rows and 5,667,710 records in total. This is settled, audited, balanced accounting, not row inserts.

Reaching 466.9 TPS on a constrained virtual machine shows the platform's consolidated design is not a bottleneck. Because processing, queuing and scheduling all happen within the platform core rather than by round-tripping to separate broker and scheduler products, there is no network hop tax on every operation — and no distributed-transaction problem to reason about when something fails.

Core processing latency covers the full accounting operation: validation, limit checks, fee and commission rule evaluation, record writes, real-time balance update and audit capture. All of it completes in 11 ms.

End-to-end latency adds gateway routing, credential verification and connection acquisition. At 20 ms the platform sits comfortably inside the sub-100 ms budget that interactive use and payment gateway callbacks demand — the difference between a checkout that feels instant and one that feels broken.

Based on measured write rates (2 GB/hour) scaled to continuous operation:

These assume continuous full load — a deliberate worst case. Real deployments have peaks and troughs, so actual storage is typically 20–40% of the continuous-load projection.

Data is organised into time-based segments so that write load is distributed and historical periods can be archived or retired independently — without downtime and without a maintenance project. That management is automatic; nobody has to remember to do it.

Sub-20 ms end-to-end write latency at sustained load is a design outcome, not a tuning accident. Three principles produce it:

1. Live balances are kept separate from history. The data a transaction must read and update to complete is deliberately small and stays that way as the ledger grows. Year five performs like year one.

2. Time-aware data organisation. Records are grouped so that queries for a period touch only that period's data. Reporting over a date range does not drag the entire ledger through memory.

3. Payment traffic is isolated from everything else. High-value transaction and approval traffic is served on its own dedicated channel, separate from reporting and general queries. A finance user running a heavy month-end report cannot slow down payment processing — a failure mode that is otherwise painfully common.

Throughput figures are only meaningful alongside what the system had left in reserve.

Across the full hour at steady state, resource utilisation stayed well below capacity — leaving ample headroom for monitoring, scheduled jobs, reporting and administrative access to run concurrently without competing with payment traffic.

This matters more than a peak number. A platform running at its ceiling has nothing left for the month-end report, the compliance extract, or the incident you did not plan for. LedgerFlow is designed so the day-to-day load leaves room for the exceptional day.

When a transaction is submitted, all of the following completes atomically before the caller gets a response — it either all happens or none of it does:

1. Validation — account existence, active status, currency agreement
2. Limit checks — per-transaction amount, velocity (hourly, daily, weekly, monthly), balance ceilings and floors
3. Debit/credit normalisation by account type
4. Fee and commission rules — automatically generating any secondary postings
5. Transaction and posting records written
6. Account balances updated in real time, with thresholds enforced
7. Running balance captured for each affected account
8. Fraud scoring, where enabled on the account
9. Audit trail recorded with user, timestamp and before/after state

That list is the point. Competing designs push limit checks, fee calculation, fraud scoring and audit into separate services — where they can each fail independently and leave your ledger in a state nobody can explain. Here they cannot: the money moves, the limits hold, the fees post and the audit lands, or nothing does.

All of it, in 11 ms on average, on a deliberately constrained machine.

Full-stack monitoring runs alongside the platform with no additional configuration.

Metrics are collected from every component every 15 seconds — connection counts and query performance, request and error rates across both API channels, edge latency, and background worker health including queue depth, processing time and retry rates.

Distributed traces follow a single request from the edge through to the query that served it, correlated with timings at every hop, so "why was that slow" is a question you can actually answer.

Logs from all components are aggregated and searchable, with one-click correlation from a log line to the trace it belongs to.

Continuous profiling shows exactly which code consumed CPU and memory over time.

Pre-provisioned dashboards cover write latency, queue depth, API latency percentiles, and business metrics such as transactions per hour and reconciliation match rates. Telemetry is emitted using OpenTelemetry, so you can route it to your existing monitoring platform instead.

The constrained test environment is intentional. On dedicated hardware the same design scales predictably:

There is no external broker to scale, licence or operate. Queuing, scheduling and hot-data access are all part of the platform core. That removes a whole category of production incidents — the broker that fell behind, the scheduler that double-fired, the message that was delivered but whose database write rolled back — because every operation, including message delivery, is covered by the same all-or-nothing guarantee.