Performance & scaling

The current hot paths#

One browser WebSocket supplies display data. Fresh marks project live risk from the latest confirmed account snapshot without an Iceberg HTTP request or database write on every tick. Hidden tabs pause their browser connection and workspace polling.

The authoritative workspace still refreshes 1.5 seconds after each prior request completes and immediately after account actions. The worker targets a one-second scan and server mark metadata has a five-second cache. A faster display does not make the server’s breach detection instantaneous.

A measured scaling path#

1. Measure response size, API latency, database wait, scan lag, stale-data rejection and order acknowledgement time.
2. Replace repeated full workspaces with authenticated account deltas after committed changes, plus full snapshots on recovery.
3. Share authoritative market streams and an upstream request scheduler across execution and risk work.
4. Partition account writers using explicit ownership leases and fencing while preserving transactional retries.
5. Replay and load-test gaps, partial fills, funding hours and midnight resets before raising concurrency limits.

Estimate costs from usage#

Current polling has an upper mathematical rate of about 0.67 workspace requests per visible session per second before network and processing time. At 1,000 visible sessions that is roughly 667 requests per second. This is a load estimate, not evidence that the current deployment can serve that traffic.

Budget from measured active session-hours, compressed payload size, average CPU/RAM, database storage, egress, authentication and RPC costs. Published provider rates change; consult Railway pricing and Hyperliquid’s upstream limits before planning capacity.

Simply adding worker replicas or enforcing an unplanned hard infrastructure cutoff can interrupt trading and risk processing. Scaling needs ownership, monitoring and operational policy as well as more compute.