Our Order Management System (OMS) consists of 3 components:
It uses an event store database:
This is very different from an SQL database. Event store databases streams of events. In this case, the events are Execution Reports from (say) a FIX server plus our internally generated events. The streams can be replayed and listened to.
To illustrate, let us consider simplified cases of placing an order and viewing a client’s list of active orders.
Placing an order
When the OMS Hub receives an order from the Trading Agent, it generates an internal event on a stream. The bridge component is listening for this event on the stream. When it sees this event appear in the stream, it generates an order request and forwards this to the FIX adapter which in turn, sends the order request to the market.
Viewing a client’s list of active orders
A trading adapter (normally a FIX adapter) is constantly receiving Execution Reports from the Exchange. The Bridge component gets each Execution Report and converts it into an event which is inserted in a stream. If the trading agent receives a request to display all a clients orders, it will request the OMS Hub to listen for Execution Request events for that client. Whenever the OMS Hub receives such a request, it notifies the trading agent which can then send an update to the client (via the proxy).
The OMS Hub is used in this fashion to provide Order and Holding subscription information for all clients. It is also used to generate other specialised data feeds such as trade feeds for settlement systems.
Event Store can be run in a cluster for redundancy purposes. Typically a cluster of 3 instances of event store would be set up. This way, even if one of the instances failed (eg. server failure), then the other 2 instances will continue to run and can check on each other. In a cloud environment, we would ensure that these instances reside on servers in different zones (hosting sites).
The OMS Bridge sits between the trading adapter and the event store. Normally it just injects events for each Execution Report received by the adapter and sends an order request to the adapter for each relevant event it ‘hears’ in the stream. However in some deployments, there can be more than one trading adapter. The bridge can then be configured to support this redundancy.