Rather than comment on the questions you’ve raised, what I’ll do here is just lay out the basic principles that underly the order management component of my trading platform, which I have honed over the past 22 years. I believe it is immune to all the situations you describe.

?

1. Maintain a model in the client containing information about all current orders. This is the client’s view of the current state of affairs, which may not be the same as the reality at any moment because of the unavoidable asynchronicity of multiple cooperating (very) loosely--coupled components.

?

2. Record the state of the model in a persistent data store that can be used to reconstitute the model after a restart of the client (for any reason). As a matter of implementation, I use a text file containing JSON-encoded records that reflect every order-related operation or event sent to or received from the API. This ‘transaction log’ can be replayed to reconstruct the model as it was at the time the last record was written.

?

3. Update the model whenever an order is placed, modified, or cancelled.

?

4. Update the model whenever an open order, order status, execution or error notification is received from the API. Note that it is execution notifications that are really in control of order state; open order and order status notifications merely provide confirmation, and an inconsistency would be a definite fault (see 6 below).

?

5. As a practical matter, the representation of orders in the model is the actual order objects used in the place order call, updated on receipt with data from open order notifications.

?

6. If at any point an irreconcilable inconsistency emerges (for example receipt of an open order notification for an order that is no longer in the model), this is a situation that needs to be investigated (typically a programming error): execution of the client must be immediately stopped since it is not safe to proceed from an indeterminate state. (This might surprise some, but where real money is at stake it is unwise to assume that the situation will somehow correct itself.)

?

7. Provide an optional capability to ensure that every order always has a protective stop-loss. For a manual trading client, this may not be needed, because there is a least a strong possibility that there will be a human present to assess unexpected conditions and take corrective action if need be. For an unattended auto-trading system, the situation may be very different.

?

I think that more or less covers it, though there is a lot of detail I’ve glossed over.

?

Sounds like a lot of work? It is!...

?

?

Richard

?