Plataformas · Software · Proveedores · Mercados
In week one, map each order path, instrument the timestamps and capture a baseline under ordinary load. By week six, the team should have replayed peak traffic, tested disconnect recovery and measured the operational cost of each option. The choice between FIX, REST and WebSockets is not a contest between three equivalent protocols. FIX defines a trading message and session model; REST commonly carries discrete requests; WebSockets provide a persistent connection for messages, whose order semantics depend on the API.
Week one: define the path and the measurement
Start by drawing the full lifecycle: client request, gateway validation, risk checks, route to venue or liquidity provider, and execution report back to the client. Mark where each clock is recorded. A broker gateway acknowledgement is not a venue acknowledgement, and neither proves that the order is working. Use monotonic clocks for durations inside a host, synchronise machines with PTP or well-managed NTP, and record clock uncertainty alongside cross-host timestamps.
Give every order a traceable client identifier and record separate timestamps for request send, gateway receive, validation result, route send, venue response, and client event delivery. For amendments and cancels, retain the parent order identifier and the request identifier. Without that separation, a fast acceptance response can hide slow risk checks, routing queues or downstream event delivery.
- Measure p50, p95, p99 and p99.9, not just the average. Report sample size and the time window for each percentile.
- Track reject rate, timeout rate, duplicate submissions, queue depth, reconnects and orders requiring manual or automated reconciliation.
- Split results by order type, venue, client region and market state. A quiet-market average can conceal a queue that grows during a burst.
A useful measurement guide should cover the whole order lifecycle, not just transport timings. Trading Technology's infrastructure coverage provides context for that broader operational view.
Use a benchmark that separates latency from recovery
The ranges below are typical market ranges for production trading APIs, not audited results for any named provider. They assume a regional network path and a functioning gateway. Public internet routing, TLS termination, risk checks, venue distance and load can move results substantially. Order acknowledgement latency runs from client send to the broker application's response; it excludes venue execution time.
Typical market ranges, illustrative production conditions
| Measure | FIX | REST | WebSocket |
|---|---|---|---|
| Order response p50 | 2-15 ms | 5-30 ms | 2-20 ms |
| Order response p99 | 10-80 ms | 30-200 ms | 15-120 ms |
| Event delivery p50 | 2-20 ms | 100-1,000 ms with polling | 5-50 ms |
| Reconnect and state recovery | 1-30 seconds if session recovery works | 1-30 seconds to reconcile state | 1-30 seconds including snapshot or replay |
These figures are not a protocol ranking. REST order responses, FIX session acknowledgements and WebSocket application events can represent different milestones.
Define the event being timed before comparing results. Run the same order mix through each path, then report both unloaded latency and latency under realistic burst rates. Capture CPU, connection count, bytes per order, gateway queue depth and the rate at which latency rises as throughput increases.
FIX: persistent sessions and explicit recovery
FIX suits workflows that need a standardised trading message model, persistent sessions and structured execution reports. Sequence numbers expose gaps.
Resend Request and Sequence Reset handling can recover missed messages, while heartbeats and TestRequest messages help identify a dead session. On the order side, ClOrdID, OrderID, ExecID, CumQty and LeavesQty support correlation and state tracking across acknowledgements, fills, cancels and corrections.
That capability has an operating cost. Teams must manage session configuration, sequence state, resend limits, counterparty certification and session resets.
A reconnect does not automatically mean the client has a correct view of every order. Test lost connections after a new order is sent but before its acknowledgement arrives; that is where blind resubmission can create duplicates. Measure recovery time, gap frequency, resend volume and the number of orders left in an uncertain state.
FIX may reduce per-message overhead compared with repeated HTTP requests, but the benefit depends on encoding, gateway implementation and network conditions. It is not a guarantee of low latency. A slow risk engine behind a fast FIX session remains a slow order path.
REST and WebSockets: simple requests, separate event streams
REST is often straightforward to integrate and operate for order entry, account queries and administrative actions. Each request has a clear response boundary, and standard HTTP tooling helps with observability.
The trade-offs include connection setup or pooling behaviour, TLS overhead, request limits and the need to define idempotency. If a client times out after sending an order, it must not assume that the broker rejected it. Use a documented idempotency key or client order ID, then query or reconcile before retrying.
WebSockets keep a connection open and can deliver order updates without polling. They can reduce event delay and repeated request overhead, but WebSocket is a transport, not a complete order protocol. Establish whether the API provides ordered events, sequence numbers, replay after a disconnect, heartbeat rules and a snapshot-plus-delta recovery procedure. If it provides none of these, the client has to detect missing state and reconcile through another endpoint.
- For REST, test request timeouts, retry policy, rate limits and duplicate protection together. Record whether a response means received, accepted or routed.
- For WebSockets, test a dropped connection during a burst, delayed event delivery and a reconnect that receives a snapshot while new events are arriving.
- For all three, inject rejects, partial fills, cancel-replace races and late acknowledgements. Verify the client order state after each sequence.
By week six, decide on evidence and failure behaviour
Use the first two weeks to instrument and validate event meanings. In weeks three and four, replay representative traffic and raise load in steps until p99 latency, rejects or queue depth breaches the service objective.
In week five, run fault tests: restart a gateway, drop a client connection, delay downstream responses and recover with orders in flight. Week six is for comparing the measured service level, engineering effort and recovery risk against the requirements of each client segment.
Keep the decision at the level of the workflow. A firm might use FIX for high-volume institutional order entry, REST for account operations, and WebSockets for streaming order and market events. That architecture is only sound if identifiers and state transitions remain consistent across interfaces. Publish the service objective with its measurement boundary, such as p99 client-to-gateway acceptance below a stated threshold, and separately specify event freshness and recovery time.
Review the benchmark after changes to gateways, risk checks, routing, network paths or vendor APIs. A protocol result from last quarter can become irrelevant after a new queue or rate limit is introduced. The mistake most readers will still make is choosing the protocol with the lowest median latency, then treating its acknowledgement as proof that the order is live and recoverable.
Preguntas frecuentes
Is FIX faster than REST for order entry?
FIX can have lower overhead on a persistent session, but the gateway, risk checks and network path often dominate. Compare the same order type and measure p50 and tail latency through the same application boundary.
Are WebSockets a replacement for FIX?
Not by themselves. WebSockets provide a persistent transport, while the API defines order messages, sequencing and recovery. Check whether the service supports replay, snapshots and reliable order-state reconciliation.
What should an order acknowledgement mean in a benchmark?
Define whether it means the broker received, accepted or routed the order. Keep broker acceptance separate from venue acknowledgement and execution, which occur later in the lifecycle.
How should clients handle an order timeout?
Do not blindly resubmit. Use a documented idempotency key or client order ID, then query or reconcile the order state before retrying, since the original request may have been accepted.
Which metrics matter beyond order latency?
Track p99 and p99.9 latency, rejects, timeouts, duplicate submissions, queue depth, event freshness and recovery time. Also count orders that remain uncertain or require reconciliation after a disconnect.
