I am a Java developer and have written a couple of high (actually medium) frequency trading systems.
These systems peg orders in the market based on some continuously changing criteria (like peg symbol A based on symbol B's price and size).
The systems work well but the low level details, like managing individual new order requests, cancels and replaces have always felt like a hack.
I've seen some systems that use the concept of an order and/or trade manager. These managers are responsible for sending commands to the broker (there is another layer which translates these commands to FIX or proprietary API, enriches messages, etc.) User doesn't worry about sequence numbers or any such detail. These managers are basically like an on/off switch, if it is turned on, then the associated order is in the market. The details of NOS, Cxl, Cxl/Rpl, etc. are irrelevant.
For example, excel obviously doesn't allow imperative operations such as "send new order," "cancel this order," etc. Rather, most excel based systems let you give a symbol, side, an indicator if order should be in the market, while the price and size is based off of some formula.
My question is, what is the best way of writing such order or trade managers? If I peg an order, which may mean that I replace my order 100 times, that means this manager has to keep track of the whole chain of replaces and continue to listen to events from all the previously sent orders (sometimes brokers/exchanges send fills even after an out is given).
Basically, what is the best way for me to hide the complexity of dealing with order life-cycle state machine and hide it behind a more declarative API?
Thanks
These systems peg orders in the market based on some continuously changing criteria (like peg symbol A based on symbol B's price and size).
The systems work well but the low level details, like managing individual new order requests, cancels and replaces have always felt like a hack.
I've seen some systems that use the concept of an order and/or trade manager. These managers are responsible for sending commands to the broker (there is another layer which translates these commands to FIX or proprietary API, enriches messages, etc.) User doesn't worry about sequence numbers or any such detail. These managers are basically like an on/off switch, if it is turned on, then the associated order is in the market. The details of NOS, Cxl, Cxl/Rpl, etc. are irrelevant.
For example, excel obviously doesn't allow imperative operations such as "send new order," "cancel this order," etc. Rather, most excel based systems let you give a symbol, side, an indicator if order should be in the market, while the price and size is based off of some formula.
My question is, what is the best way of writing such order or trade managers? If I peg an order, which may mean that I replace my order 100 times, that means this manager has to keep track of the whole chain of replaces and continue to listen to events from all the previously sent orders (sometimes brokers/exchanges send fills even after an out is given).
Basically, what is the best way for me to hide the complexity of dealing with order life-cycle state machine and hide it behind a more declarative API?
Thanks