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?


1 Answer 1


My 3 points for you:

  1. Earlier checks like pre-compliance checks for orders are usually performed.
  2. 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.
  3. Ideally order and execution ids should be kept separate because sometimes an order is partially executed.
  • $\begingroup$ Thank you: 1) yes, I left it out of the picture for simplicity; 2) very good; 3) makes complete sense. $\endgroup$
    – Den
    May 31, 2016 at 8:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.