Event Sequencing

[wbjohnston]

Introduction

A design goal of matchbook to be able to kill any matchbook service at an arbitrary point in time and be able to return to the pre-kill state just by replaying messages back to the newly created service. In order to accomplish this, there can be no ambiguity in how messages are ordered. Messages must be totally ordered. This post serves to outline possible approaches to solve this problem.

Requirements

1. Any event that alters the state of any matchbook service[1] must be part of the event total ordering.

Discussion

While the matching engine isn't the ingress point for matchbook, we should consider it the source of truth for event sequencing in matchbook[2]. Concretely this means that if there is ever contention over what the next sequence number in a given topic is whatever the matching engine says should be considered true. This topic is discussed at this section of the "How to build an Exchange" talk.

Footnotes

1. sending a LimitOrderSubmitRequest will alter the state of the matching engine by creating an order. When the matching engine acknolwedges the LimitOrderSubmitRequest with a LimitOrderSubmitAcknowledge message, the port will increment the outgoing sequence number with the client it's servicing as well as send an execution report. Both of these messages alter the state of matchbook services, so they both need to sequenced.
2. There may be exceptions to this. For example, with order cancellations. The cancel fairy(CF) will be responsible for acknowledging a "in the future" cancellation request and will be the source of truth for the state of "in the future" cancellations. When the CF submits the order for cancellation the matching engine, the matching engine will be responsible for acking it.