This can be dealt with in a few ways:
1. Co-lo at the same data centers as your broker. exchanges, etc
2. zero-copy, kernel bypass techniques.
3. machines are locked down, striped down of services, fast CPU, disk, lots of RAM.
But there are still lots of other issues like retrieving data, processing it, working with it, etc.
I'd be happy to elaborate on anything.
I presume when we're talking about such ultra low latency systems the software stack is uniquely manual memory management languages, or maybe I should say non-gc, with Rust gaining traction. At the same time the LMAX exchange runs on JVM, as far as I know. Reading some opinions you feel like for low-latency a GC language is a no-go. Maybe you care to comment on that.
Generally, I feel like when discussing these systems the wow factor of "speed of light is a factor" dwarfs the more mundane aspects. Maybe it would be enlightening to consider slower 1ms max pause systems. With such requirements you don't care about being within earshot of the exchange anymore, and you'll probably not use FPGAs, but you still need latency that is deterministic and low. When a software engineer has to develop such a system, what are the challenges, considerations, etc?
I prefer c++ but I am bias since I have been using it for 25 years. I am now doing a prototype in Python but then re-writing in C++ for production. This helps gain speed and also ensures my ideas are solid as re-writing usually flushes out problems or things I didn't think of originally.
This is false as far as my experience goes. I've personally worked at two exchanges (big ones) and they do use java. Also have interviewed with many trading firms that use java for trading platform.