Trading Systems

If you are building a trading system, the choice of messaging layer is the single most consequential infrastructure decision you will make. Pick the right one and your trading desk gets real-time market data with predictable microsecond latency. Pick the wrong one and you will spend years fighting garbage collection pauses, backpressure bottlenecks, and missed trade opportunities. We have deployed all three of these messaging systems 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 what we learned. ...

If you have ever operated a FIX engine in production, you know that the standard is not standard. Every exchange speaks a slightly different dialect of FIX 4.4. The same tag can mean different things on different venues. Session disconnect recovery differs between CME and LSEG. Drop copy behaviour varies between brokers. We have certified and deployed FIX engines across ICE, CME, LSEG, Eurex, and crypto venues. Here are the patterns that work in production and the ones that cause the most incidents. ...

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. ...