Skip to content


This sample illustrates how to build a typical trading workflow within Aeron Cluster. It does not include a gateway, but does include a simple REPL for testing interactions. A sample client interaction is as follows:

Sample Interactions

Expected Flows

rfq-simple-flow CreateRfq Command Initator AcceptRfq Command RfqAccepted Event RfqCreated Event Responder QuoteRfq Command RfqAccepted Event RfqQuoted Event Initiates RFQ Receives RFQ Notification Provides Quote Receives Quote Hits Quote Rfq Accepted Rfq Accepted State Machine Time

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.

Functional Requirements

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:

rfq-state-machine Created Quoted Canceled Countered Rejected Accepted Expired Multiple states

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 hardcoded in the cluster
  • No database - all data is held within the cluster.

The full sample is available on GitHub.