Trading

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

The conventional wisdom in capital markets has been that trading systems stay on-premise. Low latency, deterministic performance, and regulatory comfort with physical infrastructure have kept trading floors running on bare metal for decades. That is changing. We have led cloud migration programmes for tier-one banks and hedge funds, moving trading workloads to Google Cloud in under six months and passing regulatory audits on first attempt. Here is how we did it. ...

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