I too made a real time hardware level trading system back in the day, on the back of building a multi channel seismic aquisition system with a custom RealtimeOS talking to a bunch of DSP cards that each sampled a trailing flotation cable that each had multiple microphones with the entire grid going toward building up a profile of the seafloor and layers underneath along with bobbing boat|cable cancelation, etc.
Very similar architectures in many ways - with rolling DSP filters in place of trading response algorithms .. etc.
Lisp -> ASM or Lisp -> C either way code generation from a higher language was a good way to get the heavy lifting done.
what would you do if you wanna run all this on a web server instead? sorry if thats the wrong question. how does your system interact with say android or ios clients or a webapp with ui
If you have a project that you want to see done, you will be more likely to succeed using some more traditional architecture.
What I described is chasing latency at all costs. The costs are hardware costs, maintainability costs, development costs, inefficiency (yes, a lot more CPU is used than what is needed just to run the critical path fast). This is very extreme situation and it would be very unlikely to be a good tradeoff for your application.
If you have a lot of clients connecting there are different tradeoffs to think about and different possible architectures to evaluate, but I can't help you not knowing what your problem is.
The low-latency core communicates with a more normal app via messages, over a socket or through shared memory or whatever. So you have normal UI code where a user can enter an instruction, then instead of writing to a database or making a HTTP request, it sends a message to the low latency process. That should respond to acknowledge it, and it will send more messages later if it makes any trades etc.
I too made a real time hardware level trading system back in the day, on the back of building a multi channel seismic aquisition system with a custom RealtimeOS talking to a bunch of DSP cards that each sampled a trailing flotation cable that each had multiple microphones with the entire grid going toward building up a profile of the seafloor and layers underneath along with bobbing boat|cable cancelation, etc.
Very similar architectures in many ways - with rolling DSP filters in place of trading response algorithms .. etc.
Lisp -> ASM or Lisp -> C either way code generation from a higher language was a good way to get the heavy lifting done.