Live-data начинается с версии состояния, а не с транспорта
WebSocket, queue или webhook не делают данные свежими сами по себе. На каждом переходе нужен ответ на три вопроса: какое событие считается новым, как распознаётся повтор и что происходит, если correction приходит после уже опубликованной версии. Пока этих правил нет, скорость доставки лишь быстрее распространяет неопределённость.
В рабочем контуре полезно отделять raw-сообщение провайдера от canonical state. Raw хранит то, что реально пришло, вместе с provider ID, timestamp и provenance. Canonical слой связывает это с внутренними сущностями и правилами corrections. Derived данные — статистика, модели, витрины — строятся уже поверх версии, которую можно восстановить и объяснить.
Freshness измеряется на границе пользователя
Ingest lag важен, но не гарантирует, что клиент получил актуальное состояние. Между входом и экраном остаются normalization, queueing, cache, API delivery и reconnect. Поэтому полезно иметь end-to-end marker: event/version time проходит по цепочке и позволяет измерить возраст именно опубликованного состояния.
Если источник присылает ненадёжное время, это ограничение нужно зафиксировать. Можно измерять от внутренней точки приёма, но метрика тогда отвечает на другой вопрос. Лучше честный SLI с понятной границей, чем точная цифра, основанная на времени, которому нельзя доверять.
Corrections — нормальный режим, а не исключение
Спортивные данные исправляются: меняется автор события, уточняется время, отменяется эпизод, приходит более полная версия. Pipeline должен уметь применить correction, обновить materialized state и обозначить, какие downstream-результаты требуют пересчёта. Ручная правка только финальной таблицы ломает lineage и оставляет старые производные значения.
Failover между провайдерами требует общей предметной модели
Переключить endpoint легко; сложнее понять, что event, team и market действительно соответствуют друг другу. Внутренние canonical IDs и versioned mappings уменьшают риск ложного совпадения. Во время failover важны не только availability и latency, но и расхождения: другой источник может иметь иную семантику статусов или corrections.
Recovery заканчивается reconciliation
После gap или backlog недостаточно увидеть нулевую очередь. Нужно доказать, что восстановленный canonical state согласован с контрольным snapshot, пропущенные corrections применены, а клиент после reconnect получил свежую версию. Именно reconciliation превращает технический replay в завершённое восстановление.
Смежные досье: интеграционная архитектура live-систем, карта regulated betting-инфраструктуры и reference card live_state.