Problem
No load/performance measurement has been done against the current stack. The mission requires reporting measured results and environmental limitations rather than inventing scalability claims, and documenting a staged scaling path (single-process today, worker+Redis later, dedicated gateway eventually).
Repository evidence
No load-test tooling or scripts found in either package.
Risk
P2 -- valuable verification, not release-blocking for an initial controlled-beta scope, but required before any "supports N users" claim is made anywhere in docs/marketing.
Scope
Measure API p50/p95/p99, candle-query latency, WebSocket fan-out behavior, reconnection behavior under load, memory growth over a sustained run, database write throughput, backtest resource use for a representative config, chart payload size. Document the three-stage scaling path (single-process/shared-connection/in-memory-cache today; worker+Redis+horizontal-scale next; dedicated gateway+durable-stream+regional-delivery later) as a documentation deliverable, explicitly not an implementation commitment beyond stage 1.
Non-goals
Not implementing stage 2/3 infrastructure (Redis, separate ingestion worker, etc.) in this issue -- documentation and stage-1 measurement only.
Dependencies
Best run after DATA-HL-001, CHART-001, BACKTEST-001 exist so there's real load to measure, not synthetic placeholders.
Proposed implementation
A local load-test script (e.g. autocannon or a hand-rolled concurrent-request harness) run against the local dev/preview stack, with results captured in the issue and docs rather than a permanent CI gate (unless a lightweight budget-regression check is cheap to add).
Acceptance criteria
Real measured numbers (not estimates) exist for every listed metric against the actual current implementation; docs/architecture/current-state.md or a dedicated performance doc states the numbers with the exact test conditions (hardware, concurrency, dataset size) so they're not misleading out of context.
Definition of done
Measurements captured and documented; reviewer PASS confirming numbers are real (reproduced independently, not just taken from the implementer's report) per the mission's anti-fabrication requirement.
Test plan
This issue's test plan is the measurement itself -- reviewer re-runs at least one load scenario independently to confirm reproducibility.
Security review
Ensure load-testing doesn't hit real third-party Hyperliquid/CoinGecko endpoints at a volume that could look like abuse -- test against local/mocked upstream where the load target is the internal stack, not the external provider.
Accessibility review
N/A.
Observability requirements
Reuses OBS-PROD-001's metrics as the measurement source where applicable.
Performance considerations
This issue produces performance data, it doesn't need its own further performance work.
Rollback plan
N/A -- documentation/measurement only, no runtime behavior change.
Documentation requirements
Staged scalability doc (path stages 1-3) plus measured-results section, added to docs/architecture/current-state.md or a new docs/architecture/scalability.md.
Completion evidence
(added on merge)
Reviewer verdict
(pending)
Problem
No load/performance measurement has been done against the current stack. The mission requires reporting measured results and environmental limitations rather than inventing scalability claims, and documenting a staged scaling path (single-process today, worker+Redis later, dedicated gateway eventually).
Repository evidence
No load-test tooling or scripts found in either package.
Risk
P2 -- valuable verification, not release-blocking for an initial controlled-beta scope, but required before any "supports N users" claim is made anywhere in docs/marketing.
Scope
Measure API p50/p95/p99, candle-query latency, WebSocket fan-out behavior, reconnection behavior under load, memory growth over a sustained run, database write throughput, backtest resource use for a representative config, chart payload size. Document the three-stage scaling path (single-process/shared-connection/in-memory-cache today; worker+Redis+horizontal-scale next; dedicated gateway+durable-stream+regional-delivery later) as a documentation deliverable, explicitly not an implementation commitment beyond stage 1.
Non-goals
Not implementing stage 2/3 infrastructure (Redis, separate ingestion worker, etc.) in this issue -- documentation and stage-1 measurement only.
Dependencies
Best run after
DATA-HL-001,CHART-001,BACKTEST-001exist so there's real load to measure, not synthetic placeholders.Proposed implementation
A local load-test script (e.g. autocannon or a hand-rolled concurrent-request harness) run against the local dev/preview stack, with results captured in the issue and docs rather than a permanent CI gate (unless a lightweight budget-regression check is cheap to add).
Acceptance criteria
Real measured numbers (not estimates) exist for every listed metric against the actual current implementation;
docs/architecture/current-state.mdor a dedicated performance doc states the numbers with the exact test conditions (hardware, concurrency, dataset size) so they're not misleading out of context.Definition of done
Measurements captured and documented; reviewer PASS confirming numbers are real (reproduced independently, not just taken from the implementer's report) per the mission's anti-fabrication requirement.
Test plan
This issue's test plan is the measurement itself -- reviewer re-runs at least one load scenario independently to confirm reproducibility.
Security review
Ensure load-testing doesn't hit real third-party Hyperliquid/CoinGecko endpoints at a volume that could look like abuse -- test against local/mocked upstream where the load target is the internal stack, not the external provider.
Accessibility review
N/A.
Observability requirements
Reuses
OBS-PROD-001's metrics as the measurement source where applicable.Performance considerations
This issue produces performance data, it doesn't need its own further performance work.
Rollback plan
N/A -- documentation/measurement only, no runtime behavior change.
Documentation requirements
Staged scalability doc (path stages 1-3) plus measured-results section, added to
docs/architecture/current-state.mdor a newdocs/architecture/scalability.md.Completion evidence
(added on merge)
Reviewer verdict
(pending)