Docs security / security (push) Successful in 7s
Docs verify / verify (push) Successful in 13s
Conventional commits / commits (pull_request) Successful in 11s
Docs security / security (pull_request) Successful in 7s
Docs verify / verify (pull_request) Successful in 13s
43 lines
2.0 KiB
Markdown
43 lines
2.0 KiB
Markdown
# 020. Evidence for hourly sync read boundaries
|
|
|
|
**Status:** Accepted. Evidence for [ADR 019](019-hourly-reads-and-online-instrument-reference.md).
|
|
|
|
## 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.
|