Order routing latency: where the milliseconds go

1 ms can cost a passive order its place in a price-time queue, if a competing order reaches the venue first. It can also mean a stale quote, a worse fill or no fill at all.

But reducing order routing latency is not simply a matter of making every component faster. The first mistake is treating one end-to-end number as if it identifies the delay, or even describes the same part of the order journey.

A broker or prop firm needs to separate client-to-broker time, internal processing, network transit and venue response. An API acknowledgement may mean only that the broker accepted an instruction.

It does not prove that the order reached a venue, was accepted there or executed. Those are different events with different operational consequences.

The headline number hides the order path

Define the start and finish

Write down the events included in any latency figure. For an order sent by a client, the path might start when the client application submits it and end at the broker's acknowledgement. For execution latency, it might start at the broker's gateway and end at a venue acknowledgement or fill report. Mixing these definitions makes comparisons meaningless.

Measure one-way intervals between events where clocks allow it, and record round-trip time separately. Round-trip time includes the outbound path and the return message, which may not be symmetrical. A reported 2 ms round trip does not establish that the order took 1 ms to arrive.

Separate typical from tail behaviour

Median latency can look healthy while a small share of orders wait behind a queue, a slow dependency or a burst of traffic. Track p50, p95 and p99 by route, message type and market condition. Also track throughput, rejects and timeouts. A low p50 achieved by dropping or rejecting work under load is not a useful improvement.

Compare like with like: market session, venue, instrument, order type and message rate. A quiet-market test cannot explain a p99 spike during an open or news event. Keep the raw timestamps and order identifiers so that a slow sample can be reconstructed, rather than relying only on aggregated dashboards.

Where the milliseconds enter

Processing, queues and connectivity

The following are typical market ranges, not guarantees. They vary with hardware, venue configuration, geography, protocol, load and measurement method. Network figures assume a reasonably direct path. A public internet connection can add far more variability than a private cross-connect.

These figures are useful for forming a budget, not for promising a fill time. A venue's acknowledgement can arrive quickly without an execution. Conversely, a fill report may take longer to return even when matching occurred earlier. Preserve the distinction between exchange event time and the time your system received the message.

Queues are often the hidden component

Under load, a fast function can still sit behind a slow queue. Look for backlog in the client session handler, risk service, router, outbound FIX session and network interface. Record queue depth and time spent waiting, not just the duration of the code that eventually processes each message. Thread-pool exhaustion, garbage collection pauses, lock contention and synchronous logging can all turn a sub-millisecond path into a long tail.

Retries can compound the problem. A timed-out response may prompt a client to resubmit while the original order is still being processed.

Apply idempotency and duplicate-order controls, and make retry behaviour sensitive to the state of the session and downstream route. Blind retries increase load precisely when a component may already be struggling.

Routing faster is not always routing better

A smart order router has competing objectives: price, likelihood of execution, fees, market impact and speed. Sending to the venue with the lowest measured network latency may produce a worse result if its displayed liquidity is stale, its queue is long or its fill probability is low. For OTC flows, the decision may instead involve available liquidity providers, credit limits, internalisation rules and execution policy.

Make the trade-off explicit in the router's configuration and logs. For each decision, retain the available venue set, relevant prices and sizes, selected destination, reason code and any fallback.

This makes it possible to distinguish a slow decision from a valid decision that chose a slower path for a better expected outcome. It also gives operations teams evidence when a venue or route degrades.

Useful controls include:

• Set route-specific timeouts and fallbacks, rather than applying one timeout to every venue.
• Use market data freshness checks before acting on displayed prices or sizes.
• Keep routing rules deterministic where possible, and version changes so incidents can be tied to configuration.
• Test behaviour during bursts, partial venue outages and delayed acknowledgements, not only steady-state message rates.
• Review reject rates and execution quality alongside latency. A faster route that creates more rejects or adverse fills may be a regression.

Moving a service closer to a venue can reduce transit time, but adds deployment and operational complexity. Co-location may lower network latency into tens of microseconds, while leaving client access, risk checks or venue queues unchanged. Likewise, parallel venue queries can shorten selection time but increase message volume and may create duplicate exposure unless cancellation and fill races are handled correctly.

Instrument the path before tuning it

Build a timestamp map for every meaningful boundary: client receipt, validation start and end, risk check, router decision, socket send, venue acknowledgement, fill and client notification. Use monotonic clocks for elapsed intervals within a host.

For cross-host comparisons, synchronise clocks with PTP where supported and monitor clock offset. NTP can be adequate for some operational views, but it is not a substitute for precise hardware timestamps when measuring microsecond paths.

Do not assume application logs are an accurate latency record. Logging can be buffered, delayed or placed on the critical path. Prefer low-overhead event capture, then sample and correlate by a stable order identifier. Check timestamp resolution and clock discipline before interpreting small differences. If the uncertainty is larger than the latency being compared, the result cannot support a tuning decision.

A practical investigation sequence is:

1. Choose a representative slow order and reconstruct each hop from its correlated events.
2. Break total time into processing, queue wait, network transit and response time.
3. Compare the same route at normal load and during the relevant traffic peak.
4. Change one component or route policy, then check p50, p95, p99, rejects and execution outcomes.

For more coverage of the systems and providers behind broker infrastructure, see Trading Technology's platform coverage. The operational principle is narrower: optimise the segment that measurements identify, and keep the business objective visible while doing it. Which order-path interval are we actually trying to reduce in the next team meeting, and what evidence will show that the change improved execution rather than just a dashboard?

#roteamento de ordens #latência de trading #gateway FIX #conectividade com o mercado #medição de latência #verificações de risco #execução de ordens #roteamento inteligente de ordens