Synchronizing Order States and Preventing Duplicate Submissions
Summary
The document considers a manual order workflow that aims to keep little local state while relying on a remote execution system. It separates orders into proposed, submitted but awaiting acknowledgement, and actioned orders, then updates these lists as user actions, confirmations, and fills arrive. This gives a practical state model for tracking order progress across asynchronous event streams.
The response endorses those distinctions and adds pre-compliance checks before routing. It also recommends keeping order identifiers separate from execution identifiers, since one order can be partially filled through multiple executions. The discussion offers useful design principles, but it is brief: it does not specify recovery procedures for outages, reconciliation logic, or how to make duplicate prevention reliable across retries and day boundaries. The workflow is therefore a starting point rather than a complete synchronization protocol.
Key ideas
- Track proposed, awaiting-acknowledgement, and actioned orders as distinct states.
- Run compliance checks before an order is routed.
- Keep order identifiers separate from execution identifiers because fills may be partial.
- The document does not detail reconciliation or recovery behavior during platform outages.
Tags
Full text
# What approaches are there for keeping local and remote order books in sync? # What approaches are there for keeping local and remote order books in sync? Scenario: developing a custom application which defines a structured workflow for manual order submission to Bloomberg EMSX; it should minimize own persisted state and rely on the remote order book as much as possible; it should be resilient against failures and downtime and prevent duplicate order submission; it should only care about what happened within the current one day. Are there any standard patterns of handling this? Ideally not Bloomberg-specific. My current thinking is to have three lists: - proposed orders - not submitted, not executed; - submitted orders - submitted for execution, but no confirmation received yet; - actioned orders - submission confirmation received, fills are being received. Then there will be some process that will "try hard" to keep the three lists in sync: - user submits order: remove from proposed orders list and add to submitted orders list; - confirmation/fills received: remove from submitted orders list and add to actioned orders list. More practically it will reactively act on three respective sets of event streams and manage the respective order lists. Orders will have a unique ID. Execution platform-specific duplicate prevention will be used as well e.g. EMSX_REQUEST_SEQ, but it doesn't mean there shouldn't be earlier checks done. What do you think? ## Answer by Rads (score 2, accepted) https://quant.stackexchange.com/a/26321 My 3 points for you: - Earlier checks like pre-compliance checks for orders are usually performed. - Three different types of orders are correctly recognized - i.e. proposed orders but not routed, submitted orders and waiting for acknowledgement. When an order is added to the submitted queue, it should go through compliance checks and then be added orders which will be routed. - Ideally order and execution ids should be kept separate because sometimes an order is partially executed.
Shown in full with attribution under the source's licence. Licence: CC BY-SA 4.0 (Stack Exchange)
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.