Load testing a trading platform before launch

A failed launch can put £10,000 to £100,000 of revenue, client remediation and response costs at risk in an hour for a mid-sized operation. Exposure varies with client activity, product and market conditions, but a capacity test that reports only average throughput will not show whether the platform can accept orders safely when demand spikes.

Load testing before launch should answer a narrower question than "how many users can it handle?" It should establish what happens to order acceptance, risk checks, market data, position updates and recovery as demand approaches and exceeds the expected peak. The result is evidence for a release decision, not a single headline capacity number.

Model the activity that creates load

Start with the launch forecast and convert it into measurable traffic. Concurrent sessions alone are a weak proxy: a logged-in client with an idle screen consumes different resources from one subscribing to 200 instruments, refreshing balances and submitting orders. Build a workload from expected active clients, actions per client, subscription count, instrument mix and the timing of each action.

Use production telemetry where it exists, including message rates by time of day, order bursts around market opens, reconnect patterns and the ratio of new to amended orders. If the product has no production history, document assumptions and run more than one profile. A typical test plan includes a forecast case, a case at roughly 1.5 to 2 times forecast peak, and a short burst at 2 to 3 times peak. Those multipliers are planning ranges, not a substitute for understanding the product's likely demand.

Model the whole path. A client order may pass through an edge gateway, authentication, account and entitlement checks, pre-trade risk, routing, execution reports, position services and persistence.

Market data has its own fan-out and back-pressure behaviour. If the test injects orders directly into the matching or routing service, it can miss limits in the gateway, database connection pool or client-facing update path.

Separate workload types so a strong result in one does not conceal a failure in another. Include new orders, cancels and amendments, rejected orders, account reads, instrument searches, streaming subscriptions and reconnects.

Add realistic think time and session churn. A constant stream of identical requests is useful for isolating a component, but it rarely resembles launch traffic.

Measure latency tails, not just averages

Choose service-level objectives before the test. For each critical action, record the start and end points, the percentile, the load condition and the success criteria. For an order, distinguish client-to-edge time, internal processing time and venue response time. A venue round trip can vary with destination and market conditions; combining it with internal time makes an infrastructure bottleneck harder to identify.

Use histograms or equivalent distributions to calculate p50, p95 and p99. A mean can remain stable while a small share of orders waits several seconds because of queueing, garbage collection, lock contention or a saturated dependency. Record throughput and errors alongside latency. A system that responds quickly because it rejects a rising share of valid requests has not passed.

The figures below are typical market ranges for planning a launch test, not universal service levels. Protocol, geography, architecture and venue connectivity change what is achievable. Set the actual release gates against the platform's own client commitments and measured baseline.

Tag every request with a trace or correlation identifier, then carry it across service boundaries. Capture queue depth, connection pool use, thread or event-loop saturation, database wait time, cache hit rate, garbage collection pauses and network retransmits. Sampled traces help explain slow requests; unsampled counters and latency histograms show how often they occur. Keep business rejects separate from technical errors so a risk limit does not look like an outage.

Run a repeatable test, then add failure

Use production-equivalent configuration where possible: the same service versions, risk rules, database indexes, network paths and market data fan-out. Mask or generate suitable test data.

Record differences in topology and capacity, because a result from a smaller test environment is directional evidence rather than a production guarantee. Keep load generation outside the system under test and check that the generators themselves are not saturated.

A practical sequence gives teams comparable results between builds:

1. Baseline: Run a low-load profile and record latency distributions, resource use and error rates for each critical path.
2. Warm-up: Ramp traffic gradually until caches, connection pools and background jobs reach normal operating behaviour.
3. Forecast peak: Hold the expected launch peak long enough to expose sustained resource pressure, typically 30 to 60 minutes.
4. Stress: Increase load in measured steps, often 10% to 20% at a time, until a defined service limit is reached. Record where latency or errors first breach the gate.
5. Spike: Apply a short burst, such as two times forecast peak, to test queue growth and whether the service sheds load safely.
6. Soak and recovery: Run a longer profile, commonly two to four hours, then reduce traffic or restart a component and measure queue drain, state recovery and return to baseline.

Test failure modes as well as volume. Introduce a slow database response, a market data disconnect, a delayed downstream service and a node loss in a controlled environment. Observe whether retries multiply traffic, queues have bounded limits and circuit breakers recover without manual intervention. A failure test should not silently turn into an uncontrolled outage in a shared environment.

Agree beforehand on the stop conditions: rising technical rejects, breached risk controls, unbounded queue depth, data loss or a dependency becoming unstable. Keep a test operator watching those signals, with a rollback or kill switch available. Teams comparing platform and provider design choices can also use Trading Technology's infrastructure coverage as a source of industry context, but the acceptance thresholds must come from their own service objectives.

Turn results into a release gate

A report should identify the first constraint, not just the maximum traffic achieved. If p99 latency rises sharply while CPU remains low, inspect lock waits, database connections, serialised work and downstream queues.

If CPU reaches its limit but throughput continues to rise, check whether tail latency and error rates remain inside the agreed bounds. Fleet averages can hide one hot partition or a single overloaded node, so retain per-instance and per-shard measurements.

Write the release decision against observable conditions. Typical gates include:

• Forecast peak sustained for the agreed duration with p95 and p99 below the service objectives.
• Stress traffic above forecast without uncontrolled queue growth, data loss or unsafe order handling.
• Technical error rates within the limit, with business rejections reported separately.
• Critical dependencies retaining measurable capacity headroom, often 20% to 30% at forecast peak.
• Recovery tests restoring normal service within the stated recovery objective, with positions and order state reconciled.

Headroom is not a universal percentage. A service with predictable scaling and a short recovery path can operate differently from a risk engine with strict state consistency requirements. Specify whether the target is per node, per service or across the whole deployment. Also decide what happens when a gate fails: reduce the launch cohort, cap subscriptions, defer a feature, add capacity or delay release. A finding with an owner and retest date is operationally useful; a pass/fail label without one is not.

Retain the scripts, workload assumptions, build identifiers, dashboards and raw results. Repeat the same baseline after material changes to risk logic, routing, data models or infrastructure, then compare distributions rather than relying on recollection. The question worth asking in the next team meeting is: which measured failure threshold will stop this launch, and who has authority to act when it is crossed?

#pruebas de preparación para el lanzamiento #resiliencia de la infraestructura de trading #pruebas de carga de plataformas de trading #rendimiento de la plataforma del broker #monitorización de la latencia de órdenes #market data throughput #trading system capacity planning #platform stress testing