You will have to measure on your intended hardware. You should consider that 1-3micros is probably best-in-class for pure ‘software’ based trading engines (tick-to-order), or at least was when I worked in this space, admittedly over 6 years ago now.

This relies on full ethernet kernel offload to userspace, and then fast (e.g. c++ with typically little allocation / arena allocation) single-threaded engines running in a hot loop, pinned to a physical core and the kernel told to ignore that core for scheduling purposes. There are a number of things here that make it unlikely that you’ll compete successfully with engines like these, before you even get into GC, cache-unfriendly data structures (pointer chasing), branch mis-prediction etc.

That said, if you can successfully trade via a strategy that is not so latency focused then I think the beam would make a pretty great starting point. GC is per-process and generally constrained. Process isolation gives you some reliability guarantees.

I would probably run each instance of a strategy (e.g. per instrument ) in its own process. If you have multiple strategies trading the same instrument, you may need some way to amortize their orders, if you’re not allowed to cross yourself in the markets you trade.

Importantly, I would have your data feeds (e.g. order-book) update ETS tables and then just ‘ping’ your strategy to wake up and re-evaluate the data inside them. Sending market data as messages into the mailbox of your strategy risks you trading on out-of-date information.

As background, I was working on FPGA based trading engines over a decade ago where latencies were around 250ns from memory, some of this was simply bounded by how quickly you could clock in bits off the wire, make a decision and start clocking bits out. I believe we may even have had a version that started clocking bits out before the full packet had been ingested, with ip-checksum poisoning used to ‘abandon’ the packet if there was no good order to be sent. Fun times.