ADR-0035: Event Governance И Data Lineage
Статус
Принято.
Контекст
Pin использует микросервисы, Kafka events, replicas, snapshots, Elasticsearch projections, ClickHouse facts и exports. Без единого стандарта владения данными и управления событиями сервисы могут начать принимать решения на stale replicas, публиковать несовместимые события, дублировать ownership или терять происхождение данных в аналитике и поиске.
Особенно критичны деньги, KYC, AML, operational safety, provider callbacks, partner payouts и regulatory evidence. Для этих потоков нужны явный source of truth, прослеживаемость transform chain, freshness SLA, reconciliation и безопасное изменение event contracts.
Решение
Вводим два архитектурных стандарта:
- Data Ownership И Data Lineage;
- Event Governance.
Каждый runtime artifact получает владельца: service schema, entity, replica, snapshot, Elasticsearch index, ClickHouse fact, export и Kafka event. Source of truth остается в owning service PostgreSQL или специализированном owner storage. Elasticsearch, ClickHouse, Redis, frontend state и replicas не становятся operational source of truth.
Kafka events проектируются и меняются через governance process: producer ownership, typed envelope/payload, compatibility rules, consumer impact analysis, replay/DLQ rules, deprecation plan и review checklist. Публикация и потребление бизнес-событий выполняются через MassTransit Outbox/Inbox.
Lineage обязателен для replicas, projections, reports и exports: source service/model, source events, consumer/job, transform version, target model, freshness SLA, watermark и rebuild strategy.
Последствия
- High-impact commands fail closed при stale/unknown replicas или projections.
- Event changes требуют анализа consumers и не могут ломать payload без major migration.
- Elasticsearch indexes и ClickHouse tables должны иметь documented rebuild/backfill strategy.
- Reconciliation становится обязательной частью provider, financial, projection и saga flows.
- Документация service events, replicas, search documents и analytics facts должна ссылаться на эти стандарты.
- Запрещены cross-service direct database access, arbitrary JSON payloads и silent schema drift.
Альтернативы
Оставить правила в отдельных service docs. Это снижает upfront cost, но приводит к разным interpretation ownership, freshness и event evolution между сервисами.
Использовать только schema registry без governance документа. Это проверяет часть схемы, но не фиксирует source of truth, replay behavior, consumer impact, PII policy, lineage и reconciliation.
Обратные ссылки
Автоссылки: где используется этот документ.