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?