Load testing costs and benchmarks before a trading launch

£25,000 is a typical planning budget for a scoped load test before a trading product launch. Spend can be under £10,000 for a small team using existing test infrastructure, or exceed £50,000 when the work needs specialist support, a production-like environment and several rounds of fixes and retests. The cost of getting the test wrong is less visible: a launch-day queue, rejected orders or a market data delay that turns into an incident.

Those figures are typical UK market ranges, not quotes or audited costs. The useful question is not how many virtual users a supplier can generate. It is whether the test can reproduce the platform's order, risk, pricing and reporting paths, then show where capacity stops scaling.

Price the whole test, not just the traffic generator

A load generator is rarely the largest line item. Engineering time goes into defining representative traffic, preparing accounts and instruments, keeping test data realistic, instrumenting the system and interpreting results. A test that drives traffic without matching the platform's dependencies can produce a neat graph and little operational evidence.

For a UK broker or prop firm, typical planning ranges for a focused campaign look like this:

• Internal engineering: 3 to 8 person-days, often £1,500 to £7,000 at typical loaded staff costs. This assumes the team already has a test harness and can use the environment without a major rebuild.
• External performance specialist: typically £8,000 to £30,000 for scenario design, execution and a findings report. Complex FIX flows, multiple regions or repeated test cycles can push the fee higher.
• Cloud compute and traffic generation: typically £500 to £5,000 for a short campaign. Cross-region generators, sustained high message rates or isolated capacity can cost £5,000 to £15,000 or more.
• Environment and observability: allow £2,000 to £12,000 if the test needs extra application nodes, database capacity, logging retention or monitoring licences. Existing shared tooling may reduce this, but shared environments can also distort results.
• Retest and change window: reserve 20% to 40% of the initial effort for fixes and a repeat run. A report without time to verify remediation leaves the launch decision unresolved.

A typical scoped campaign therefore lands around £8,000 to £35,000 when internal preparation and test infrastructure are already in place. A vendor-led campaign with environment work and multiple retests can reach £20,000 to £60,000.

Exclude the cost of a platform redesign or production capacity uplift from that estimate. Treat those as separate investment decisions.

Teams comparing platform components can use Trading Technology's infrastructure coverage to frame the architecture questions, but the workload and acceptance thresholds need to come from the firm's own production telemetry.

Build a workload that resembles a trading day

Start with observed production peaks, not an average day or a vendor's maximum session figure. Collect at least several weeks of minute-level data if available, including busy market opens, news periods, expiry dates and internal risk events. If the product is new, use comparable instruments and conservative assumptions, then label those assumptions in the test plan.

Model the work generated by each session. A connected user may subscribe to many prices, refresh balances, submit an order, amend it, cancel it and request a position view. A single order may pass through authentication, limits, margin checks, routing, execution reporting and persistence. Test those dependencies together. A test that measures only the web front end will not reveal a saturated risk service or a database write bottleneck.

Include distinct traffic classes rather than treating every request as equal:

• Logins, session refreshes and account or position reads, with a realistic ramp and a sharp reconnect burst.
• Market data subscriptions and updates, including symbol changes and reconnect behaviour after a dropped stream.
• New, amend and cancel requests over the APIs and FIX sessions used by the product, with business rejects separated from technical failures.
• Risk checks, execution reports, balance updates and downstream persistence, including any batch or reconciliation work that shares infrastructure.

Use a steady-state phase, a ramp, a short burst and a soak. A 30 to 60 minute soak can expose memory growth, connection leakage and queue accumulation that a five-minute peak will miss. Run a separate recovery test: stop or throttle a dependency and observe whether queues drain, retries multiply traffic or stale orders remain unresolved.

Agree the test window with operations and vendors. Do not send synthetic orders to a live venue unless the venue and compliance controls explicitly support it.

Compare results with useful operating thresholds

The table gives typical market planning ranges for a medium-sized retail trading workload. They are reference bands, not universal service levels. A crypto venue, a multi-asset CFD broker and a prop firm with centralised evaluation accounts have different traffic shapes. Set the acceptance target from the product's expected peak, contractual limits and production baseline. Measure internal acknowledgement separately from venue execution time.

Do not read the table as a capacity claim for any named platform. The ranges are typical market reference points, and a design may need materially different targets.

Track p50, p95 and p99 latency, throughput, error rate, CPU, memory, database connections, queue depth and downstream response time on one timeline. A healthy average can hide a severe p99 problem. A high request rate can also mask a growing backlog if the system accepts work faster than it completes it.

Set separate thresholds for technical errors, business rejects and expected throttling. For example, a limit breach that returns a valid rejection is not the same failure as a timeout before the risk engine responds. Record the response code, service and request identifier so operations can trace the slow path. Trading Technology's platform reporting can provide broader context on the systems firms operate, while the actual pass criteria must reflect the release being tested.

Run the campaign as a release gate

Make the load test a controlled engineering change, with named owners for the workload, environment, risk controls and release decision. A useful sequence is:

1. Choose the release path. List the services and vendors involved in a real order from client request to confirmation. Include market data, authentication, risk, routing, execution reports and persistence.
2. Set the workload and limits. Specify expected peak sessions, order rate, subscription volume, burst duration and recovery time. Define thresholds for latency percentiles, technical errors, queue depth and resource headroom.
3. Validate the harness. Check that generated traffic reaches the intended services, timestamps are comparable and test data does not trigger unrealistic account or instrument behaviour. Verify that monitoring captures each dependency.
4. Run a baseline, then increase load. Start below forecast peak, step up in controlled increments, and hold each level long enough to observe queues and resource use. Stop if safety controls or test accounts behave unexpectedly.
5. Test failure and recovery. Introduce a controlled delay or outage in a non-production dependency. Confirm that timeouts, retries, circuit breakers and reconnection logic behave as designed, then measure backlog clearance.
6. Fix, repeat and record. Retest material changes under the same workload. Store the script version, configuration, build, environment details and results so a later release can be compared on like-for-like terms.

A go/no-go decision should state which workload passed, which limits were breached, what was changed and what risk remains. It should not rest on a single headline such as maximum users. Keep a rollback or traffic-control plan available if launch traffic exceeds the forecast, and define who can invoke it. If capacity is close to the limit, reducing a product's initial audience or instrument set may be safer than relying on autoscaling that has not been tested across the full order path.

The question worth asking in the next team meeting is: which production workload and failure threshold would make us stop the launch?

#infraestructura de prop firm #pruebas de estrés de datos de mercado #pruebas de carga de plataformas de trading #broker platform capacity #order throughput testing #trading latency benchmarks #load testing costs #pre-launch performance testing