1---2name: scale-readiness-review3description: Reviews code and architecture for scalability bottlenecks, capacity limits, data growth, query cost, queue behavior, and failure modes. Use for higher volume, batch growth, more tenants, larger ledgers, or market-data throughput.4---56# Scale Readiness Review78## Workflow9101. **Establish assumptions**: peak req/job rate, batch/file frequency, ledger growth/day, tenant skew, provider limits, retention needs; if unknown, state conservative assumptions.112. **Inspect hot paths**: N+1 queries, missing indexes, unbounded list/export/reconciliation endpoints, full-table scans in jobs, large locking transactions, sync work belonging in a job, queue jobs missing retry/DLQ/backpressure, stale-truth caches.123. **Review data growth**: partitioning/archival, pagination contracts, tenant isolation, rebuild paths for derived balances/projections, reconciliation strategy for drift.134. **Recommend**: covering index/uniqueness constraint, bounded-page batching, outbox/worker for slow effects, idempotency/retry before more concurrency, metrics for queue/latency/failure/drift, a narrow load test.145. **Verify**: query plans, unit/integration tests for pagination/batching/idempotency, benchmarks for hot functions, load tests where a harness exists, metrics/logs for visibility.1516## Output Format1718```text19Finding: unbounded reconciliation query can scan all ledger rows.20Impact: batch runtime grows with total history, not daily volume.21Fix: page by posting date and account id; add an index on (...)22Verification: run query plan and reconciliation integration test.23```2425## Guardrails2627- Do not optimize before the path is proven relevant to scale.28- Do not cache financial truth without freshness/invalidation rules.29- Do not increase concurrency until idempotency/locking is clear.30- Do not propose a rewrite when a bounded query, index, or queue boundary solves it.