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
Programming? Seriously, like so often there is no best way. It depends a lot on your architecture in place. There are so many ways to skin that cat, it is not even funny anymore. * Do you trading systems use an application server of some kind? * Are you event driven or message driven (with a message bus below)? * Do you use a database or not? What I would do is have a "client component" (class library) working against the manager service communicating with a message bug (in an application server). The message bus gives you your own command system to work against the order manager service. This abstracts you from most things... and you can actually use it to send (immutable) objects around. The client API makes sure that you can easily do things like data binding (remember: ui component may come in handy to see orders in the market) and / or work at least aainst items such as a list of orders from your system. Make sure your state engine is sound - like cancel request orders stay in the system until.... the cancel is confirmed. A message bus allows you to run every trade system in it's own thread (or a threadpool for all) and use a central manager, AND will handle issues of serialization automagically. And there you go. That requires some infrastructure though - I simply do not know how you set that up at the moment.