This sample illustrates how to build a typical trading workflow within Aeron Cluster. It does not include a gateway. For the sample, the client interaction is as follows:
In building the sample, the following requirements and non-functional requirements were defined. These in turn influenced the implementation. The choices made will not be valid for most projects, but they serve to show how an RFQ server might be built with Aeron Cluster.
To keep the example easy to understand, only two users will be allowed to interact with an RFQ - the requester and responder. The Requestor is the user that requests the RFQ, and Responder is the user that responds to an RFQ. In addition to the requester and responder, the system may expire the RFQ as needed. Other requirements:
- RFQ supports only 1 response; the first user to respond is granted exclusive access to the RFQ to completion.
- The RFQ requester can cancel before a quote is supplied, but after that, the quote will need to be rejected
- The RFQ requester and responder can run a negotiation in which they can counter, accept or reject the negotiation
- Once accepted, rejected, canceled or expired, the RFQ can no longer be interacted with.
For an individual RFQ, the complete state machine is:
This state diagram shows the possible transitions possible within the RFQ State Machine. A sampling of the legal transitions:
- When a Requestor creates an RFQ, the RFQ state is Created. From there is may transition to Quoted once a responder provides a quote, to Expired if the RFQ expiry time passes without response and the RFQ may be Canceled if the Requestor cancels it.
- When a RFQ is Quoted, the quote may be countered by either party, and if the other side of the counter accepts the counter quote, it will move to Accepted. If the Countered state does not get a response within the timeout, it will move to Expired.
The expiry timers be handled with Aeron Cluster timers - although it is important to note, from the state machine point of view, the timer is an external I/O call.
Non Functional Requirements¶
The RFQ Server aims to meet the following non-functional requirements:
- Users are fully managed at the gateway level - the cluster holds no data about user sessions;
- No database - all data is held within snapshots.
The full sample is available on GitHub.