A trading system designed for small, predictable event-to-action delays: latency boundaries, tails, throughput, queueing and trading controls.
Low-latency trading system
A low-latency trading system is trading infrastructure designed to keep the delay between specified market events and trading actions small and predictable under its intended load. For a quant strategy, that delay determines which market state an order can respond to and when a cancellation can take effect. A faster calculation is useful only if the complete path delivers the intended, authorised action while the information remains relevant.
There is no universal microsecond threshold that makes a system “low latency”. The requirement comes from the strategy, venue, event rate and consequences of acting late. Low latency is one objective within a production trading system, alongside correctness, availability, recovery and risk control.
Put endpoints around the claim
“Order latency” is incomplete without a start and an end. Useful measurements include:
Boundary
What it answers
Application accepts a feed event → order handed to transport
How long did this application path take?
Network adapter receives market data → adapter transmits an order
How long was the measured wire-facing response path?
Order submission → exchange acknowledgement received
These measurements cover different work. A transport handoff does not establish that a packet has left the adapter. An acknowledgement does not establish a fill. A cancellation request does not establish that the order can no longer execute.
Timestamp placement is part of the specification. Linux distinguishes adapter-generated timestamps, kernel receive timestamps, transmit scheduling and transmit software timestamps. It also warns that transmit-completion timestamps can describe a hardware completion report rather than actual transmission. Match identifiers to events rather than assuming timestamp arrival order matches send order. See the Linux timestamping interface.
For elapsed time on a compatible local clock, a monotonic counter avoids wall-clock jumps. Python's perf_counter_ns() returns an integer counter; its nanosecond unit does not promise nanosecond accuracy. Across hosts or adapter and host clocks, establish clock domains, synchronisation error and timestamp meaning before subtracting readings. Otherwise clock offset can masquerade as latency.
Follow one event through the path
Consider this fictional trace, with all timestamps on one common clock. A feed event is accepted by the application at 0 µs, the order book is updated at 20 µs, a decision is ready at 55 µs, pre-trade checks accept it at 70 µs, and the order is handed to transport at 95 µs.
Fictional common-clock trace: endpoints 0, 20, 55, 70 and 95 microseconds give decode and book 20, decision 35, risk controls 15, and encode and handoff 25 microseconds, totalling 95 microseconds. Network transit and exchange response are excluded.
Figure 1. Four contiguous intervals total 95 µs between application feed acceptance and order transport handoff. These are invented scenario timings, not measured performance or a benchmark.
The arithmetic is simple; choosing an honest boundary is the harder part:
For this event, adjacent intervals add because they partition the same elapsed path. If a stage waits in a queue between its timestamps, that waiting is included. If processing overlaps across threads, adding each thread's CPU work can double-count elapsed time; measure the actual path endpoints instead.
The tail is a property of complete events
A median describes a typical observation. Tail latency describes the slow end of the distribution, often reported through a high quantile, such as p99. State the sample window, count, quantile convention and workload. Track failed and timed-out events separately as well as successful ones; excluding slow failures can flatter the result. Google's monitoring guidance connects latency distributions with traffic, errors and saturation.
Component p99 values cannot generally be added to obtain end-to-end p99. An exact fictional counterexample uses 100 events and two serial stages:
Events
Stage A (µs)
Stage B (µs)
Total (µs)
98 ordinary events
1
1
2
One delayed in A
100
1
101
One delayed in B
1
100
101
Define sample p99 by the nearest-rank rule: the 99th sorted observation out of 100. Each stage has p99 of 1 µs, so their sum is 2 µs. The complete path has p99 of 101 µs. The slow events differ across stages. Preserve paired observations and calculate each complete event's latency before taking its quantile.
Throughput and queueing change the answer
Throughput counts completed work per unit time; latency measures the delay for individual work. A system can process many events per second while individual events spend too long waiting. When arrivals temporarily outpace service, a backlog can grow even if average daily traffic looks manageable. A bounded buffer caps stored work; it still needs an explicit policy when full.
Batching can spread overhead across several messages while delaying early messages in a batch. Preallocated objects, local memory and reduced shared-state contention are possible engineering choices, not guarantees of a particular latency. The DPDK 25.11 guide explains these memory and throughput/latency trade-offs. Measure the chosen design under representative bursts, with its actual controls and telemetry enabled.
Measure from an arrival boundary that includes queue waiting. A load generator that waits for each reply before submitting more work may reduce demand precisely when the system stalls, concealing the backlog an independent arrival stream would create. Record offered load, completed throughput, queue depth, message age and drops alongside latency.
Speed must preserve the trading decision
The critical path needs valid market state, consistent order state and pre-trade controls. Price and size limits, exposure reservations and stale-data checks protect the meaning of a fast decision. If overload makes state unreliable, the system needs a defined response: for example, block affected new orders, reconcile outstanding instructions and recover valid market data before resuming. Silently discarding incremental book updates can leave a fast but incorrect book.
A kill switch also has a documented scope. For example, CME's Kill Switch blocks new entry and cancels specified orders, but lists exceptions including mass quotes and some market states. Do not interpret invoking a control as proof that every exposure disappeared immediately.
The owned Live Execution Monitoring lesson develops outstanding-order reservations, cancellation races and reconciliation. Its public preview is available without membership; the full lesson requires membership. Those operational invariants belong alongside the latency distribution when assessing whether a faster system remains safe to trade.
