What does a 21st Century Exchange matching engine look like? part two...

How do you implement a matching engine from a clean sheet of paper design?

In the initial post in this series I offered five core functions:

1. Receive orders from member firms
2. Add an Order to an OrderBook.  That Order then does one of three things (potentially more than one sequentially)
1. executes in full
2. executes in part
3. rests on the order book
3. Manage the state of the order book
4. Any execution must be notified back to the member firm that sent the order
5. Any execution must be notified to market data recipients with the appropriate level of anonymity

With some parameters/constraints which were:

• Implementation in Java using OpenJDK
• Use a sensible number of threads (Client Simulator x2, Main, one thread per order book)
• Use of QuickFIX/J with FIX 4.4
• No High Availability
• No Disaster Recovery
• Write clean code – use annotations, enumerations, interfaces, constants, exceptions
• Write the code so that JavaDoc can execute to provide documentation for developers who look at this in the future.
• Do not spend more than six days on this.
• Use MIT license and open-source the whole thing
• Use https://github.com/AlignmentSystems/MatchingEngine
• Build in client simulators such that orders & executions can be sent in.
• Build a stub for market data, if possible use SBE-FIXP-SOFH for the market data implementation (start with TCP/IP unicast but again, if possible, switch to UDP/Multicast for the Transport)
• Limit Orders only (I have promised myself I won't got into a market microstructure rant but unlike some exchanges I think there is an imperative to ethical behaviour in system architecture)
• Simple partial fills as first implementation with order restatement and more realistic behaviour to follow

Let’s look at the five core functions first:

1. Receive orders from member firms==>DONE, FIX4.4 interface for inbound limit orders.
2. Add an Order to an OrderBook.
1. Add an Order to an OrderBook: executes in full==>DONE
2. Add an Order to an OrderBook: executes in part==>Not yet started.  This is not a big ask, the orderbook member has to be updated to reduce the size of the order by the executed amount, partial execution sent out and market data transmitted)
3. Add an Order to an OrderBook: rests on the order book==>DONE
3. Manage the state of the order book==>DONE FOR FULL-FILL
4. Any execution must be notified back to the member firm that sent the order ==>DONE. Execution Report sent to member for order acknowledgement and execution report for execution sent to member
5. Any execution must be notified to market data recipients with the appropriate level of anonymity==>DONE. UDP/Multicast implementation of Simple Open Framing Header and Simple Binary Encoding of anonymised market data message.

 

The parameters/constraints were specified as:

• Implementation in Java using OpenJDK==>DONE
• Use a sensible number of threads (Client Simulator x2, Main, one thread per order book) ==>DONE
• Use of QuickFIX/J with FIX 4.4 ==>DONE
• No High Availability ==>HA NOT DONE AS PLANNED
• No Disaster Recovery ==>DR NOT DONE AS PLANNED
• Write clean code – use annotations, enumerations, interfaces, constants, exceptions ==>DONE
• Write the code so that JavaDoc can execute to provide documentation for developers who look at this in the future. ==>DONE
• Do not spend more than six days on this. ==>DONE
• Use MIT license and open-source the whole thing ==>DONE
• Use https://github.com/AlignmentSystems/MatchingEngine ==>DONE
• Build in client simulators such that orders & executions can be sent in. ==>DONE
• Build a stub for market data, if possible use SBE-FIXP-SOFH for the market data implementation (start with TCP/IP unicast but again, if possible, switch to UDP/Multicast for the Transport) ==>DONE
• Limit Orders only (I have promised myself I won't got into a market microstructure rant but unlike some exchanges I think there is an imperative to ethical behaviour in system architecture) ==>DONE
• Simple partial fills as first implementation with order restatement and more realistic behaviour to follow ==>DONE

What next steps are there for enhancements?

• Partial fills.  
• HA/DR
• FIX Orchestra 
• 24x7 Operation 
• Volume testing
• Market Data Enhancements
• Scaling-out
• Kill-Switch
• Binary Order Interface

Partial fills

This is something a proper matching engine must have. Maybe one day to implement this.

Cancel-on-disconnect

This is something a proper matching engine must have.  The challenge is to implement the logic at a scale that fits the use-case – consider the logic in an institutional equity exchange versus an institutional options exchange.  The throughput requirement is quite different in each case. Do you “spoof” incoming FIX cancel messages or iterate through an orderbook in-memory and remove affected messages?

HA/DR

This is something a proper matching engine must have. Along with the thematically linked cancel-on-disconnect.  This impacts on all aspects of the system – persisting parts of the system data to disk while not impacting performance is a balancing exercise.

FIX Orchestra

As the creator of the forerunner to FIX Orchestra FIIDL (FIXInteractive Interface Definition Language) and the person who chose the name FIX Orchestra, I have been involved since the start. See for example this and this.

Implementing FIX Orchestra for the Alignment Matching Engine is one quick win which is a solid contender for future development after implementation of cancel-on-disconnect and partial fills.

24x7 Operation

This would be relatively easy to follow the guidelines available here from the work by the working group 

To deliver this we would also have to modify one of the dependencies of the Alignment Matching Engine.  The dependency is QuickFIX/J which is not 24x7 compatible – yet!

Volume testing

This is a much more complex task to see the real bottlenecks in the platform. Use something such as Corvil to spot problems.

Market Data Enhancements

Provide an orderbook snapshot service on a periodic basis over UDP/Multicast

Provide an orderbook replay service over TCP/IP

Scaling-out

At the moment the whole platform runs on one box.  This is not viable for production use. The APIs between the components would need to be reworked inside the implementation, such that

• the number of FIX engines can be increased and distributed to multiple boxes
• the number of OrderBooks can be increased and distributed to multiple boxes
• market data distribution can be performed from a specified set of UDP/Multicast ports

Kill-Switch

Alongside cancel-on-disconnect essential for an institutional exchange

Binary Order Interface

An implementation using SBE, SOFH and FIXP can provide a fast to parse message format that can contribute to a low-latency environment.  Parsing, coercion and other requirements of the string-based FIX message format mean that moving to a binary interface is a worthwhile performance improvement.

 

 

Screengrab of JavaDoc generated from the code

 

 Code plus gradle build files are all here