On the fast path, you need to make the decision to trade, check compliance, credit etc and execute the trade. Not just quickly but quicker than everyone else.
This translates into a low latency problem, as others have said. But unlike many real time engineering problems, the environment is actively working against you so it's a perpetual race to the bottom. To the point that the speed of light is annoyingly sluggish.
The other big area is trading strategy. The majority of the work here is done offline and is more about analysing a lot of tick data than latency. Big data tooling is pretty common here and machine learning is getting more prevalent.
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.
Also, I'd say that this implies that profiling-centric development is obligatory.
I read an article a few years back about latency, not just about switching decisions at the router level, but due to the actual physical distance the light/electrons in the physical media need to travel; the HFT servers need to be very close to the exchange.