Good plan, I am an experienced coder but still had an obscure scenario last year where my code flipped a contract 200 times at market costing $10k. Needless to say, I put in place an "N orders in 10 minutes" type filter.
what you wrote here is a little mind boggling. are you saying you keep no internal order state relying completely on the api? if so, you sure are putting a lot of faith in that api, and also, something is wrong with these 'general principles' you speak of if they don't allow for one of the pinnacles of failsafe systems: redundancy. let me give you just one scenario that would destroy you with that setup... you're a market maker, you have a gazillion open limits out, your execution line goes down, market moves 1%, you're stuffed to the gills IN REALITY but have no idea of current state because you're waiting for the api to tell you. i don't know about you, but i'd rather be aware that i'm out of sync and be able to do something about it, than be out of sync and have no idea what's going on.
Thanks very much for the offer but I'm not looking for my design or code to be peer reviewed. Just looking to have a broad discussion at the conceptual level. I'd never post any proprietary materials on a public forum anyway. Just for starters it makes anything relating to intellectual property a total nightmare.
Interesting. Do you use an arbitrary number for N? In running some of the wilder variety of market data through my app I've seen occasions (unscheduled news releases etc) when I could be legitimately flipping a position multiple times per second.
Well in the order case it is probably wrong to keep only API state. I should have said in the marketdata case. For example, you subscribe to a symbol. Keeping that state twice causes headaches. Even in the order case, I have seen order state get out of sync with API order state, but I have yet to see intra-day positions as reported by the API get out of sync with what it really is. Every API I have ever seen allows you to query for positions/open orders on login. In the case where you do not have that, then naturally you have to keep state in case of a crash. Even in this case, relying on stale state is extremely dangerous. Not only that, exchanges have a short fuse when you try to do things like cancel orders that are not live, or cancel orders that are filled, etc. Once or twice is ok, but do that 10,000 times and you are going to hear it. In the case of the CBOE and probably all the option exchanges, the quoting engines will auto cancel your quotes if your heartbeat is dolwn for a certain amount of time, something like 15 seconds but I don't recall exactly. I don't know what the ECNs do.
I'm a bit lost here. So are you saying that if your internal app logic needs to know the state of an order you put a request into the API and wait for a callback each time?
No. I mean if the API has a class that keeps state, I use that. I don't create a new class, and copy the state from that class to my class in the need-for-speed case.
OK, I can see now why you are prepared to accept the tight coupling and the maintenance overhead that this design approach brings. As you said earlier, it all depends on the required speed of execution and my needs are obviously not as great as yours. I have adopted a decoupled approach throughout with a fundamental principle being that I should be able to port the app to a different API with the minimum of hassle.