Low Latency

Building trading systems for institutional capital markets is fundamentally different from building general-purpose distributed systems. A market data feed that delivers prices 100 microseconds late is worthless to a market maker. An order management system that drops a single message during a volatility spike can trigger a regulatory investigation. This guide covers the architecture patterns, technology choices, and operational practices we have used to build trading infrastructure at HSBC, Credit Suisse, Deutsche Bank, and NatWest Markets. ...

If you run a trading system that cares about microseconds, you cannot afford the overhead of traditional observability. Sidecars consume CPU. Log shippers add latency. Metrics exporters create failure dependencies. And yet you still need to know when your exchange connections are dropping packets, when a syscall is running long, and when your TCP handshake to the venue is stalling. eBPF — extended Berkeley Packet Filter — solves this. It runs sandboxed programs inside the Linux kernel without modifying kernel source, loading modules, or touching application code. The kernel verifier rejects unsafe programs at load time. Goldman Sachs requires eBPF experience for production engineering roles. Their low-level systems engineering listing specifically asks for “experience with eBPF and tracing for observability in production” and “knowledge of RDMA or kernel networking internals beyond the socket API.” This is not a conference talk about future potential. It is a job requirement at one of the world’s largest financial institutions. ...

If you are comparing Aeron vs Kafka vs Chronicle Queue for your capital markets messaging layer, the choice determines whether your trading desk operates at microsecond or millisecond latency. Pick the right one and you get predictable sub-10μs market data delivery. Pick the wrong one and you will spend years fighting GC pauses, backpressure, and missed trades. We have deployed all three in production at tier-one banks — Aeron for exchange gateway connectivity, Kafka for settlement and risk workflows, and Chronicle Queue for deterministic journaling on the trading floor. Here is the real-world comparison based on those deployments, including the aeron vs kafka latency gap and where chronicle queue fits in. ...

The belief that cloud cannot deliver sub-millisecond trading latency is outdated. The constraint is not the cloud provider — it is how you architect within the cloud. Firms that treat AWS, GCP, or Azure as a data centre with better networking get data-centre performance. Firms that treat the cloud as a programmable substrate get latency numbers that surprise their counterparties. We have deployed trading systems on AWS and GCP that consistently achieve round-trip latencies under 500 microseconds for order-to-acknowledge paths. The architecture is fundamentally different from on-premise trading infrastructure, but the performance is comparable. ...

Edge computing brings processing closer to the data source. For financial services, this means processing transactions, analysing risk, and detecting fraud at the network edge — closer to customers, exchanges, and data sources — rather than in a centralised cloud data centre. Edge computing is not new. Trading firms have colocated with exchanges for decades to minimise latency. But the cloud providers’ edge offerings — AWS Wavelength, GCP Distributed Cloud, Azure Edge Zones — have made edge computing accessible to a broader range of financial services firms. ...