У сообщения о событии есть полезные данные и служебное окружение. Объясняем, как отличать повторы, понимать задержку и не путать версии формата.
Сообщение должно объяснять само себя
Склад сообщил, что посылка передана курьеру. Внутри сообщения есть номер отправления и сведения о передаче. Но получателю нужно понять ещё несколько вещей: кто прислал сообщение, какое именно событие оно описывает и как читать его содержимое. Эти сведения удобно представлять как конверт вокруг основного сообщения.
Это образное название служебного окружения, а не обязательный отдельный файл. Содержимое отвечает на вопрос «что произошло», а окружение помогает его распознать и обработать. Полезно договориться о таком устройстве заранее: сообщение может попасть к человеку, который не присутствовал при создании системы и не знает её негласных правил.
Источник и номер события работают вместе
В стандарте CloudEvents событие имеет источник и идентификатор. Их сочетание позволяет отличать события; повторно переданное то же событие может сохранять прежний идентификатор. Номер заказа при этом не заменяет номер события: с одним заказом может произойти несколько разных изменений.
Представим два независимых склада, которые оба присвоили сообщению номер 41. Без источника их легко перепутать. С указанием склада понятно, что это разные события. А два сообщения от одного склада с одинаковым идентификатором требуют проверки на повтор. Конкретное правило обработки повторов должна определить принимающая система: наличие номера само по себе ничего не удаляет и не исправляет.
Время события и время получения различаются
В условном примере посылку передали в 09:00, а сообщение дошло до получателя в 09:07. Семь минут описывают задержку доставки сведений. Это не вторая передача посылки и не новое событие только потому, что сообщение появилось позже.
Перед сравнением важно проверить часовой пояс и смысл каждой отметки. Время появления записи в принимающей системе может отличаться от времени самого события. В CloudEvents отметка времени события необязательна, а правила её заполнения описаны отдельно в спецификации. Поэтому отсутствие такой отметки нельзя автоматически объявлять нарушением любого стандарта обмена. Для своего процесса команда должна явно определить, какие времена ей нужны и кто за них отвечает.
Две разные версии
Версия формата конверта и версия содержимого решают разные задачи. Первая сообщает, по каким правилам устроено служебное окружение. Вторая, если предусмотрена договорённостью, помогает различать варианты бизнес-данных: например, когда в сообщении о передаче посылки добавили новое описание места получения.
Пояснения CloudEvents отдельно обсуждают изменение типов и схем данных. Схема — описание ожидаемого устройства содержимого. Само наличие ссылки на неё не обеспечивает совместимость. Отправителю и получателю всё равно нужно договориться, какие изменения допустимы. Нельзя считать, что новая версия стандарта конверта автоматически объясняет все изменения сведений о посылке.
Что проверить при разборе непонятного сообщения
Начните с одного конкретного события. Уточните его источник, идентификатор, тип, смысл временных отметок и ожидаемый вариант содержимого. Затем спросите, пришёл ли такой же экземпляр повторно. Эти вопросы помогают составить проверяемое описание, даже если читатель пока не умеет писать программы.
Допустим, сотрудник видит два уведомления о выдаче одной посылки. Совпадение номера посылки ещё не доказывает повтор: уведомления могут относиться к разным действиям. Полезно сопоставить именно идентификаторы событий и отправителей. После этого можно обсуждать, что должна была сделать принимающая система. Иначе исправление легко начать с неверного предположения о двух выдачах.
Небольшой договор между участниками обмена
Для учебного процесса можно составить короткое описание без технической разметки: кто отправляет сообщение, какое действие оно означает, где искать номер события, какой момент обозначает время и как сообщают об изменении содержимого. Отдельно запишите, к кому обращаться при непонятной версии. Это предложенная памятка для обсуждения, а не новый универсальный стандарт.
Проверять такую договорённость удобно на трёх вымышленных примерах: обычное сообщение, повторная доставка и сообщение после изменения содержимого. Если участники по-разному объясняют один из примеров, правило стоит уточнить до подключения реальных данных. Конверт помогает задавать эти вопросы, но не заменяет проверку самих сведений и поведения получателя.
Как перейти к практике
Курс «Data Engineer для начинающих» подойдёт для знакомства с задачами передачи и подготовки данных. Полезная цель обучения — уметь объяснить, какие сведения нужны получателю и почему одного полезного содержимого сообщения иногда недостаточно.
