Topic Structure
The topic structure is made up of the following four parts:
| Field | Limit | Description |
|---|---|---|
| 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 Topic Modelling Scenario
The following scenario highlights some of the considerations when deciding on topic structure.
Given a trade with 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).
In this instance, the "Trade Source" and "Book" fields can be used for the Topic Source and Topic Group respectively, then for the Topic Id segment, there are two potential options:
Option 1 (Preferred)
| Source | Group | Id |
|---|---|---|
| Trade Source | Book | Trade Id |
If the "Trade Id" field is used, 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.
Option 2
| Source | Group | Id |
|---|---|---|
| Trade Source | Book | Versioned Trade Id |
If "Versioned Trade Id" field is used, 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 require 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.