- Home
- Benchmarks
Performance by the Numbers
Settler is benchmarked continuously against realistic high-volume financial data workloads. Numbers below are from the production engine, not synthetic demos.
Latency by Stage
| Stage | p50 | p95 | p99 |
|---|---|---|---|
| API Gateway + Auth | 4ms | 8ms | 14ms |
| Rule Evaluation | 12ms | 22ms | 38ms |
| Evidence Hash Generation | 45ms | 90ms | 115ms |
| Mismatch Classification | 6ms | 11ms | 18ms |
| Audit Log Write | 3ms | 7ms | 12ms |
| End-to-End (Full Run) | 280ms | 620ms | 980ms |
Throughput by Scenario
Stripe ↔ QuickBooks
- Volume
- 50k transactions
- Throughput
- ~8,200 rec/s
- Evidence
- 2.1 MB
Bank Payouts ↔ Internal Ledger
- Volume
- 200k rows
- Throughput
- ~9,800 rec/s
- Evidence
- 8.4 MB
Multi-source (3 systems)
- Volume
- 100k transactions
- Throughput
- ~6,400 rec/s
- Evidence
- 5.7 MB
High-cardinality FX
- Volume
- 25k multi-currency
- Throughput
- ~7,100 rec/s
- Evidence
- 1.9 MB
Determinism Guarantees
Settler enforces determinism at the engine level. The following are verified in CI on every merge:
- Identical input data and identical rules → byte-identical output hash
- Replay of any stored run confirms original evidence hash
- Rule version fingerprint captured in every evidence bundle
- Concurrent runs on same inputs produce independent but identical hashes
- Engine output is floating-point safe — all amounts handled in integer cent representation
Methodology
Benchmarks run continuously via a k6-based load test suite distributed across multiple AWS regions. Each test scenario uses fixture data that mirrors production-scale financial transaction patterns: bursty webhook events, concurrent reconciliation jobs, high-cardinality foreign key joins, and multi-currency FX amounts.
Latency Measurement
All latency figures are client-side wall-clock times including full network round-trip. Internal stage timings are captured via structured spans at the engine boundary and summed for end-to-end reporting. The edge CDN is included in all p95/p99 measurements.
Throughput Measurement
Throughput is measured as records successfully reconciled per second under sustained load. Each scenario runs for 120 seconds at target concurrency before recording throughput to allow JIT warmup. Numbers reflect the engine running at 80% CPU utilization on a standard cloud instance type.
Determinism Verification
Determinism is verified by running the same reconciliation job 3 times with identical inputs and confirming that all three evidence SHA-256 hashes are byte-identical. This test runs on every merge in CI. A determinism failure is a blocking CI failure.
Benchmark results reflect the production engine under controlled load test conditions. Actual performance in your environment will vary based on data volume, network topology, instance size, and concurrent load. Run the quickstart locally to measure performance on your own hardware.