Skip to main content

Message Structure

All messages have a consistent structure defined as follows:

This structure applies whether SBE is being used as the serialization mechanism or whether an alternative serialization is being used, in which case alternative payloads will be automatically wrapped within an envelope which provides these header fields.

SBE Header

Contains the following standard SBE header fields. More details of these can be found in the Simple Binary Encoding documentation. These fields are automatically applied when using the API and therefore should not need to be set manually.

FieldDescription
blockLengthThe block length of the SBE message
templateIdThe type of the message
schemaIdThe schema of the message
schemaVersionThe schema version of the message

KeyHeader

The SBE Header is the standard SBE header. KeySquare conscientiously decided not disrupt the standard SBE structure. Instead, the KeyHeader contains various metadata required for our applications. These fields are fixed offsets within the SBE byte buffers ensuring performance.

Contains the following fields:

FieldResponsibilityDescription
sequencerIdPlatformA unique identifier applied by the Sequencer.
sequencerNanoTimePlatformThe timestamp that this message was received by the Sequencer.
relayNanoTimePlatformThe timestamp that this message was received by the Relay supplying the message to the application.
messageTypePlatformAn indicator that provides information about the type of relay that provided the message, e.g. Cached, Live.
applicationIdApplicationThe unique identifier of the application that published the message.
flagsApplicationSee below for more details.
topicSourceApplicationThe Topic Source (see topic structure).
topicGroupApplicationThe Topic Group (see topic structure).
topicIdApplicationThe Topic Id (see topic structure).
inceptionNanoTimeApplicationApplication provided timestamp which indicates when an item of data was created.
sourceSequencerIdApplicationOptional field that can be used to store the sequencer number of an incoming message that has triggered a message to be published - this can be useful in cause-and-effect tracking.

Message Flags

The following boolean flags can be set to control various messaging behaviours. When creating new messages, the default value for all of these flags will be false. These flags only need to be set when a non-default behaviour is needed.

FlagDescription
editableIndicates whether edit requests can be made for this data. Messages are not editable by default
ephemeralIndicates whether the message should be cached. Messages are cached by default
eternalIndicates whether the message should remain in the cache and not be auto-evicted when an application that published the data goes offline. Messages are not eternal by default and will therefore participate in auto-eviction. Messages cannot be both ephemeral and eternal.
voidedIndicates whether the message is valid for use. Voided messages are evicted from the cache. Messages are "valid" by default, i.e. not "voided"