Order routing latency: where the milliseconds go

Week one: a marketable order takes 34 ms from the broker's API edge to venue acknowledgement at the 99th percentile, and the team cannot say which hop accounts for the difference from its 12 ms median. Week six: the same route has a measured latency budget, a known queueing point and a controlled change that cuts the tail without increasing rejects.

That is a representative infrastructure exercise, not a result from a named firm. The example assumes an electronic broker or prop firm with a client-facing gateway, synchronous pre-trade controls, an order management system (OMS), and a FIX connection to a venue. The client network is measured separately: an internet connection can add tens of milliseconds before the order reaches the broker, masking improvements inside the stack.

Trace one order across the stack

Take a new limit order submitted over an authenticated API. The gateway terminates TLS, checks the session and message shape, applies rate limits, then passes a normalised order into the internal routing path. A risk service checks buying power, position limits and instrument rules.

The OMS assigns an identifier, records order state and selects a destination. A FIX session serialises the order, sends it over TCP, and waits for a venue response.

Each component has a different idea of completion. The gateway can report that it accepted a request before the order has passed risk. An OMS can persist a new order before the venue has received it. A venue acknowledgement means the order passed the venue's intake checks; it does not mean the order filled. Execution reports arrive later and should be measured as a separate event.

For this walkthrough, assume the broker runs the gateway, risk and OMS in one region, with a dedicated connection to a venue in the same metro area. The order path is mostly serial because risk approval must precede routing. Some work, such as metrics publication or non-blocking audit delivery, can happen asynchronously, but moving a safety check off the critical path changes the control model, not just the timing.

Instrument the order with a correlation ID that survives gateway, risk, OMS and FIX processing. Record monotonic timestamps at ingress, after validation, risk request and response, OMS enqueue and dequeue, socket write, venue acknowledgement and client response. Wall clocks help correlate services, but clock skew makes them a poor measure of short intervals. Use monotonic durations within each process and synchronise hosts for cross-process investigation.

Separate service time from waiting time

A 4 ms risk check may mean 4 ms of computation, or 300 microseconds of computation after 3.7 ms waiting for a worker. Those need different fixes.

Emit spans or structured events for both queue entry and service start, then record service finish. If the system only logs request start and response, it shows elapsed time but cannot tell an overloaded pool from a slow rules evaluation.

Likewise, a slow OMS-to-venue interval can include time in the OMS dispatch queue, FIX encoding, a socket buffer, kernel scheduling, the network and venue intake. Split the interval at the boundaries you control. Capture socket write completion and FIX acknowledgement separately. Packet capture can help diagnose retransmissions and delayed sends, but it adds operational overhead and does not replace application timestamps.

Use a consistent clock definition. For example, report gateway ingress to venue acknowledgement, and label it as broker ingress to venue ack.

Do not compare that number with client send to fill time. Track p50, p95 and p99 by route, order type and session, alongside throughput and rejects. Averages hide bursts, while a single worst-case sample is often a transient event rather than a useful service measure.

The following figures are typical market ranges for individual stages under ordinary operating conditions, not service guarantees. They are indicative per-order elapsed times, not audited results for a particular firm. Client access varies by geography; venue and broker figures assume a healthy same-region route. A cross-region path or congested session can sit well outside these ranges.

Do not add every table value and call the result expected latency. The client-to-edge leg is outside the broker's internal budget, stages may overlap, and percentiles do not add arithmetically.

Build a measured end-to-end distribution from the same order population, then use component timings to explain it. A useful internal dashboard shows both total ingress-to-ack latency and the stages that make up each trace.

Find the tail before changing the route

Suppose the median internal path is 8 ms, but p99 reaches 34 ms during the opening minutes of a session. If risk service time remains steady while risk queue wait grows from 0.2 ms to 14 ms, optimising rule evaluation will barely affect the tail. The likely issue is capacity, burst handling or work assigned to the same pool, not the arithmetic in the risk rules.

Correlate latency with arrival rate, queue depth, CPU throttling, garbage collection, database pool use, FIX session state and venue response time. Check whether spikes align with market opens, scheduled risk recalculations, reference-data updates or a particular instrument. Break results out by route and order class. A firm may have a healthy average across all traffic while one venue session or a small set of symbols causes most late acknowledgements.

• Queue growth with stable service time: add capacity only if the downstream dependency can absorb it, or apply bounded admission and back-pressure. An unbounded queue turns overload into stale orders.
• Long risk spans with remote reads: test whether hot state can be served locally with a clear freshness limit. Keep the control owner responsible for the risk decision and define what happens when state is unavailable.
• FIX writes are quick but acknowledgements are late: check network RTT, packet loss, retransmits, session sequencing and venue response time. A successful socket write is not proof that the venue received the order.
• Latency jumps after persistence: inspect commit policy, database contention and synchronous replication. Relaxing durability may shorten a path but changes recovery and audit guarantees.
• Only one route has a long tail: compare physical path, session capacity, venue throttles and broker-side dispatch queues before changing smart order routing logic.

Routing choices also trade latency against execution quality and control. A direct venue connection can remove an intermediary hop, but the broker then owns more session management, certification and failover work. A smart order router may take longer to evaluate multiple destinations yet improve price or fill probability. Measure order-to-ack alongside fill rate, slippage, rejects and cancelled quantity; a faster acknowledgement alone does not establish a better outcome.

For a broader view of the platforms and connectivity decisions behind broker and prop-firm stacks, see Trading Technology's infrastructure coverage. Keep the latency investigation tied to the specific path under test. A change that helps one venue, order type or geography may move the bottleneck elsewhere.

Use week six to validate the change

In week one, establish the baseline and make the order trace complete before tuning. In the middle of the exercise, reproduce the tail with production-like bursts in a test environment. Check whether the benchmark includes the same risk rules, persistence mode, FIX settings and downstream fan-out as production. Synthetic orders that skip those controls can produce convincing but irrelevant numbers.

By week six, compare the same route and workload before and after one change. Report p50, p95 and p99, sample count, order rate, reject rate and error rate. Include the measurement window and note market conditions. A 20% p99 improvement from a quiet hour is not comparable with a baseline taken during a market open. Keep the original traces so that the team can verify whether the intended span changed or another component simply became less busy.

Use a controlled rollout with an explicit rollback trigger. For example, canary a new dispatch pool on a small share of eligible orders, then watch tail latency, queue depth, session errors and risk outcomes.

Keep venue selection and order semantics unchanged during the test if the aim is to assess a software-path change. If several variables change together, attribution becomes difficult.

• Set a latency objective for each boundary, not only for the full path, and identify which team owns each measurement.
• Define safe queue limits, overload behaviour and the point at which new orders are rejected rather than allowed to age in a backlog.
• Test reconnects, venue slowdowns and risk-service degradation. Confirm that retries cannot duplicate an order or bypass a control.
• Review the result with operations and dealing teams, including whether a faster route altered fills, rejects or incident handling.

Latency work is an operating discipline, not a one-off code change. Traffic patterns shift, venue paths change and added controls can create new synchronous waits.

Preserve trace identifiers, percentile dashboards and a repeatable load test so that future releases can be compared against the same definitions. In the next team meeting, which timestamp gap in the order path can the team prove is the largest, and who owns reducing it?

#order routing #trading latency #pre-trade risk checks #p99 latency #order management system #venue connectivity #FIX connectivity #smart order routing