Topic Structure
The topic structure is made up of the following four parts:
| Field | Limit | Decription |
|---|---|---|
| Type | - | The data type of the message made up of a schema identifier and type identifier |
| Source | char(20) | The source of the message, this could be an application or a semantic source. |
| Group | char(20) | A natural grouping that can be applied to help partition the data. |
| Id | char(36) | An identifier of the message. This is appropriately sized to allow use of UUIDs. |
The combination of Type, Source, Group and Id should be able to uniquely identify an item of data.
Topic Structure Guidance
The following is a suggested usage of the topic structure for different data types:
| Type | Source | Group | Id |
|---|---|---|---|
| Instrument | Instrument Source | Product Group | Instrument Id |
| Order | Order Source | Product Group | Order Id |
| OrderBook | OrderBook Source | Product Group | Instrument Id |
| Position | Position Source | Book | Instrument Id |
| Price | Price Source | Product Group | Instrument Id |
| Quote | Quote Source | Rfq Source | Rfq Id |
| Rfq | Rfq Source | Product Group | Rfq Id |
| Trade | Trade Source | Book | Trade Id |
Example Scenario
In KeySquare, a trade has the following fields.
- Trade Source (The venue it came from)
- Book (The book it belongs to)
- Trade Id (e.g. 12345, this is constant)
- Versioned Trade Id (e.g. 12345.1 and 12345.2 for the first and second revision of a trade respectively).
Note that the trading system allows trades to be updated, in which case a new revision is created and reflected by the version field.
In this instance, there are two potential options for the topic structure.
Option 1 (Preferred)
| Source | Group | Id |
|---|---|---|
| Trade Source | Book | Trade Id |
If Trade Id field is selected over Versioned Trade Id then it allows the same topic to be used for a trade regardless of whether the trade version is updated. This can be helpful when making use of the last-value cache that the platform provides. In which case, a late joining application could subscribe to all data from a given Trade Source and Book and be provided with the current state of trades without having to work through old historic versions.
For cases where all versions of trades are needed, e.g. regulatory reporting, the platform's archived data features can be used, which will provide all versions of a trade to subscribers.
Option 2
| Source | Group | Id |
|---|---|---|
| Trade Source | Book | Versioned Trade Id |
If Versioned Trade Id field is selected over Trade Id then it allows all images of a trade to be available in the last-value cache that the platform provides. In this instance, a late joining application could subscribe and receive all versions of trades. In some cases, this may result in additional business logic, for example an application which is performing position tracking, it would need to filter older versions of trades so that only the latest versions are taken into account - this logic would not be required by Option 1.
It is also worth considering upstream trading systems, not all may provide a versioned trade id which would require additional complexity within applications bridging data.