Colocation vs cloud: measure latency, not the claim

Cloud is not inherently slower than colocation. The useful comparison is between two measured paths for a specific workload, including their tail latency, failure modes and operating costs.

Colocation puts equipment in or near an exchange facility. Cloud runs it on provider-managed infrastructure, usually in a selected region and availability zone.

Neither label tells you the latency from your strategy process to the order gateway, or what happens during a route change. The infrastructure coverage at Trading Technology is a useful source of context, but a deployment decision needs measurements from your own path.

Measure the route, not the label

Break the order path into segments: strategy to risk checks, risk checks to gateway, gateway to network edge, then edge to venue. Record each segment where possible.

A colocation deployment may reduce the network distance to a venue, but application queues, kernel scheduling, NIC settings and gateway processing still contribute to total time. A cloud deployment can have a short route too, if the service and venue are close and the network path is stable.

As broad planning ranges, a well-tuned colocated network hop within a facility may measure in tens to hundreds of microseconds. A cloud-to-venue path can range from hundreds of microseconds to several milliseconds. These are typical market ranges, not service guarantees: venue location, carrier, route, instance type and measurement boundary can change the result substantially.

Define the endpoints before comparing. A client-side timer around a call may include application work and queueing; a NIC hardware timestamp measures a narrower part of the network path. Use the same definition in both environments. Where available, use PTP-synchronised clocks and hardware timestamps. Record clock offset and uncertainty, rather than treating timestamps from unsynchronised hosts as directly comparable.

Build a fair benchmark

Run the same application build, risk rules, market-data replay and order mix in both environments. Keep message sizes and rate profiles consistent. If the hardware differs, document CPU model, frequency policy, core pinning, NUMA placement, NIC and kernel settings. Cloud instance families can share underlying hardware; record the instance type and any placement controls, and repeat tests to expose host-to-host variation.

Capture timestamps at meaningful boundaries: message received, strategy decision complete, risk check complete, order handed to the NIC and acknowledgement received. Separate exchange or gateway timestamps from local ones unless their clock relationship is known. If the venue does not provide a usable timestamp, report the measured round trip as a round trip, not as one-way latency.

Keep an event record with:

• P50, p95, p99 and p99.9 latency, with sample count and test duration.
• Jitter, measured consistently, plus packet loss, retransmissions and connection resets.
• CPU run-queue delay, context switches, interface drops and queue depth.
• Market state, message rate, order type, region, route and deployment configuration.

For deeper infrastructure reporting, Trading Technology's platform coverage can help frame the wider vendor landscape. It cannot replace a repeatable test using your own order flow.

Read the tails and the sample

The median describes the ordinary event. It will not show whether one order in a thousand stalls behind a full queue or a noisy neighbour.

For a strategy sensitive to execution timing, p99 and p99.9 often matter more than a small improvement in p50. At one million observations, p99.9 represents roughly one thousand events in the tail, enough to inspect patterns rather than rely on a handful of outliers.

Run separate tests during quiet periods and high message rates. Keep warm-up events out of the steady-state sample, but retain startup and reconnect tests as separate results.

Report each run as well as the aggregate. A good median from one run is weak evidence if another run has a much wider tail.

Do not average percentile values across runs. Pooling observations can hide a bad run, while averaging p99s has no straightforward statistical meaning. Show the per-run distribution, the event count and the conditions. If comparing two options, calculate the difference for matched events or test windows and state the uncertainty.

Compare the full monthly cost

Compare service costs on the same basis: production capacity, connectivity, support, resilience and engineering time. The figures below are typical market ranges in major financial centres, in USD. They are planning estimates, not quotes, and vary with location, contract term, power, provider and service level.

These line items are not equivalent services. A rack quote does not include the cost of servers, spares, deployment and hardware refresh. A cloud compute figure does not include engineering to tune networking, licences, reserved capacity or a second region. Add connectivity, monitoring, backups, support, recovery capacity and the staff time needed to operate each model. Check whether cloud tests include cross-zone traffic and egress, and whether colocation costs include diverse carriers and redundant power.

Test failure as well as steady state

Low latency is only useful if the system behaves predictably during faults. Cloud can make capacity changes and regional recovery easier to automate, but failover may alter network paths, DNS resolution and warm-up behaviour. Colocation offers control over hardware and network design, but spare parts, remote-hands response and recovery equipment need explicit plans.

Use a controlled checklist before selecting a production design:

1. Replay the same market-data and order profile in both candidate environments, with a fixed build and recorded configuration.
2. Capture at least one million events across multiple runs where feasible, and report p50, p95, p99 and p99.9 for each run.
3. Test peak message rates, process restarts and network interruption; measure recovery time, lost messages and duplicate-order protection.
4. Verify clock synchronisation, packet counters, alerting and log retention on the actual production hosts.
5. Price the complete resilient design, including a second path or site, connectivity, support and operational staffing.

Define failure thresholds before the test. A route switch that restores service in seconds may still be unacceptable for a system that needs uninterrupted order handling. Record both the time to recover and what the application did while recovering.

Choose by workload and evidence

Colocation is a strong candidate when measured venue proximity, deterministic network behaviour or specialised hardware is a hard requirement. Cloud may fit workloads that scale unevenly, depend on managed services, or need rapid regional recovery.

A broker or prop firm may also run a split design: latency-sensitive gateways near venues, with research, reporting or less time-critical services elsewhere. That adds operational boundaries, so ownership of data movement and failover must be clear.

Use the measurements to set an acceptance envelope, not to chase a single best-case number. Define maximum tail latency, tolerated packet loss, recovery objectives and monthly cost for the workload. This week, run one paired, timestamped replay of your production-shaped order path in the two candidate environments.

#latência de trading #medição de latência #infraestrutura de trading #cloud trading systems #exchange colocation #network jitter #infrastructure costs #disaster recovery