More services of the CEX define their data formats (messages formats) in our in-house YAML-based format. Every message has frame, containing message class unique identifier, sequence number and actual length of message. Each messages set (set of messages belonging to the same logical data stream) we call  a scheme. Scheme can be used both for dynamically unpacking messages from incoming stream and (preferably for low-latency services) generating C++ code for creating and reading messages using statical (for better performance) or dynamical approach: latter approach allows not to recompile client even is case of some changes in the messages scheme, while former ensures virtually no overhead for decoding messages. Variable-length messages, nested messages and lists are supported. We find our approach having some features similar to Google Protobuf. Bindings for Python language are also generated from messages schemes. Data stream (“link”) can expose its scheme to clients, making data stream self-described.
Middleware / presentation layer are widely using DTO structures. These classes are being serialized in JSON format. When DTO is routed through communication channels, Redis MQ or UDP, it may be packed by GZip algorithm - depending on the channel’s settings.