ksv741
e0bceea936
2.0 KiB
020. Evidence for hourly sync read boundaries
Status: Accepted. Evidence for ADR 019.
Measurements
The backend persisted-read budget was measured with npm run test:performance
using a synthetic SQLite dataset: three accounts, 100,000 operations per
account, 200 instruments, and 5,000 candles per instrument. The run used Node
24.21.0 on Apple M1 Pro with 32 GiB RAM and a failing synthetic upstream after
population. It measured 100 reads per route family, excluding transport
limiter cost.
The generated evidence is written by the test to its temporary
persistent-budget.json file. This is a repeatable measurement, not a
production SLA: it does not include network latency, real T-Bank quotas, or
multi-process SQLite contention.
The successful run produced a 617,263,104-byte SQLite database and measured zero upstream calls during the persisted-read phase. Backend p50/p95 response times were approximately 1.3/2.3 ms for account and portfolio reads, 3.9/4.5 ms for account operations, 6.7/7.2 ms for aggregate operations, 40.0/41.5 ms for account income analytics, and 128.1/134.2 ms for aggregate income analytics. These figures are local synthetic measurements only.
Durability
The migration durability check passes against a separately built repository at the pre-history migration prefix. It verifies preservation of users, sessions, T-Bank connection data, bank-card data, operations, categories, archive state, and replay behavior across migration and restart.
The executed command was node test/bank-cards-durability.cjs with a separately
built pre-history repository. It completed with PASS durability.
Limits
The configured T-Bank start limiter is TBANK_RATE_LIMIT_PER_SECOND, default
5 per backend instance. The hourly scheduler therefore remains a single
durable reservation owner; the measurement does not justify increasing this
limit or changing the hourly cadence. Any production tuning requires current
T-Bank documentation and a new measurement with the deployed topology.