TL2: дизайн формата сериализации — решения, заимствования и ошибки

Архитектура системы диктует требования к тому, как ее части общаются между собой. Пока система остается монолитом с небольшим числом хранилищ, порядок обновлений контролируем, и совместимость протокола может держаться на договоренностях и аккуратности команд. Рост проекта и самой компании естественным образом приводит к микросервисам: обновление участников перестает быть централизованным, и всё, что раньше держалось на дисциплине, должно быть строго выражено в самом протоколе и в инфраструктуре вокруг него.

Наш внутренний формат сериализации TL создавался на заре компании: быстрый и предельно экономный, он честно служил годами, но не закладывался на то, как будет меняться сама система. Мы создали новую версию формата так, чтобы сохранить скорость первой и добавить гарантии, которых ей не хватало: вдохновлялись решениями существующих форматов, но брали только то, что отвечает нашим типовым сценариям. В докладе я покажу этот путь целиком: на живом примере разберем, как ломается формат без метаинформации о собственной структуре, а затем шаг за шагом, на уровне байтов, соберем новый. Посмотрим, какая модель данных из этого получается и что она дает: от эволюции схем, не требующей внимания прикладного разработчика, до навигации по сериализованным данным без их разбора. Отдельно остановимся на собственных ошибках проектирования и на сравнении с Protobuf: не «какой формат лучше», а какие сценарии оплачивает каждое из решений.

В завершение сверим ожидания с измерениями. Из доклада вы унесете набор решений, применимых к собственному протоколу или формату хранения.

Технологии: TL2 (открытый формат сериализации и язык схем), TL1, кодогенерация; Protocol Buffers и MessagePack как референсы для сравнения.

Целевая аудитория: инженеры, работающие с форматами данных и эволюцией схем; проектировщики собственных IDL, протоколов и storage-форматов; пользователи Protobuf/Avro, которым интересно, какие дизайн-решения формата за что отвечают.