Интеграционная архитектура live-систем

Очереди, streaming, replay, provider integration и технические границы компонентов. Observability вынесена в отдельный эксплуатационный track, чтобы архитектура не смешивалась с мониторингом.

Что здесь считается архитектурой

Это dossier о границах компонентов и потоках состояния: ingest, canonical model, queue/stream, replay, cache, delivery. Наблюдаемость и security вынесены в самостоятельные треки, поэтому архитектурная схема здесь отвечает прежде всего на вопрос «где живёт authoritative state и как он восстанавливается».

Хорошая схема показывает не названия микросервисов, а ответственности: кто принимает raw event, где появляется внутренняя сущность, какой слой применяет correction и откуда клиент получает snapshot. На каждой границе полезно обозначить version marker, retry semantics и recovery path.

Отдельный вопрос — provider failover. Если внешние IDs просочились во все сервисы, смена источника становится миграцией всей платформы. Canonical IDs и versioned mappings уменьшают эту связанность.

Продолжение: Live-data Platforms, Observability, sports data pipeline.

Что схема должна позволять проверить

По архитектурной схеме должно быть возможно пройти один event от приёма до client snapshot, найти точки persistence и replay, а также понять, где version state меняет владельца. Если схема показывает только boxes и arrows без этих границ, она пригодна для презентации, но слаба для incident response.