Channel Catalog Drafts By Release Unit — Первые channel families, producers, consumers и delivery expectations

Версия: 1.0
Дата: 24.04.2026
Статус: Готов к обсуждению

Назначение документа

Этот документ фиксирует первый implementation-oriented каталог async channels по release units платформы.

Его задача — определить:

• какие channel families реально нужны первым release units;
• кто выступает producer и кто выступает primary consumer;
• какие каналы являются domain event channels, а какие work/job channels;
• какие delivery, retry, replay и retention expectations должны считаться baseline;
• где проходят первые boundaries для будущих AsyncAPI channel catalogs.

Этот документ не является финальным broker-topology документом. Он является bounded operating draft для того, чтобы async layer перестал быть только taxonomy и стал implementation-relevant.

Опорные документы

• AsyncAPI Skeletons And Event Envelopes — Первый bounded asynchronous contract artifact
• Payload Family Outlines For High-Value Channels — Первые bounded payload shapes для ключевых async channels
• Payload Examples For Top Critical Events — Первые example payloads для ключевых async событий
• Initial Event Taxonomy — Первичная таксономия событий платформы
• Eventing And Queue Baseline — Событийная шина, очереди и асинхронная дисциплина платформы
• Implementation Ready Breakdown — Первые release units, execution slices и порядок практической реализации
• OpenAPI Skeletons And Resource Families — Первый bounded synchronous contract artifact
• Observability And Incident Response — Наблюдаемость и реагирование на инциденты
• Release Engineering And Migrations — Релизы, совместимость и эволюция схем

Почему Этот Документ Нужен Отдельно

После появления:

• event taxonomy;
• async skeleton;
• implementation-ready breakdown;

уже недостаточно просто знать, что “такие-то события существуют”.

Команде нужен документ, который впервые отвечает на более практические вопросы:

• где именно появляется конкретный channel family;
• какой release unit за него отвечает;
• это stream, integration channel или queue/job family;
• кто должен быть producer;
• кто должен быть первым consumer;
• насколько критичны retry, replay, dead-letter и ordering expectations.

Без этого async architecture снова расплывётся либо в общую таблицу event names, либо в broker-specific импровизацию по месту.

Главный Принцип

Первый channel catalog должен быть:

• release-unit-aware;
• bounded by execution contours;
• operationally honest;
• replay-aware where required;
• small enough to реально сопровождать первую implementation wave.

Channel Classes В Этом Документе

Domain Event Channel

Используется, когда platform truth уже meaningfully changed и это изменение должно быть видимо downstream contours.

Integration Signal Channel

Используется, когда изменение должно быть bounded fan-out signal между контурами, но не обязательно представляет самостоятельную новую truth record.

Work / Job Channel

Используется, когда системе нужно выполнить bounded work item с retry, scheduling или recovery semantics.

Cross-Cutting Expectations

Для first-wave channel families по умолчанию действуют следующие ожидания:

• delivery baseline: at-least-once;
• consumer discipline: idempotent where required;
• replay capability: mandatory for replay-sensitive families;
• dead-letter handling: mandatory for poison/non-repeatable failures;
• observability: backlog, lag, age, retry rate, poison rate;
• correlation: correlation_id mandatory;
• ordering: only where domain-significant.

RU-2 Supplier Intake And Canonicalization

Main Domain Event Channels

supplier.intake.*

• class: domain/integration hybrid
• producer: supplier intake runtime
• primary consumers:
  • ingestion orchestration runtime
  • observability/operations contour
• retention expectation: medium, enough for intake diagnostics and incident review
• replay expectation: low on the event itself, high on the underlying job/source trace

supplier.normalization.*

• class: domain event channel
• producer: normalization runtime
• primary consumers:
  • mapping/governance contour
  • observability contour
• ordering expectation: per-ingestion-run, not global
• replay expectation: high

mapping.*

• class: domain/governance event channel
• producer: mapping and review contour
• primary consumers:
  • governance/review contour
  • canonical model updater
• retention expectation: high enough for review trace
• replay expectation: medium to high

canonical.*

• class: domain event channel
• producer: canonical model update contour
• primary consumers:
  • offer materialization contour
  • projections/read side
  • governance/observability
• ordering expectation: per-entity ordering where meaningful
• replay expectation: high

Main Work / Job Channels

job.ingestion.parse

• producer: intake orchestration
• consumer: ingestion worker runtime
• retry expectation: yes, bounded with DLQ

job.ingestion.normalize

• producer: parsing/ingestion orchestration
• consumer: normalization worker runtime
• retry expectation: yes
• replay expectation: strong

job.ingestion.replay

• producer: operator/governance/runtime controls
• consumer: replay-capable ingestion runtime
• replay expectation: first-class capability
• special note: must preserve traceability to original source material

RU-3 Offer And Publication

Main Domain Event Channels

offer.materialized

• class: domain event channel
• producer: offer materialization contour
• primary consumers:
  • publication integrity contour
  • search/read projections
• replay expectation: high

offer.updated

• class: domain event channel
• producer: offer runtime
• primary consumers:
  • projections
  • quote/commercial contour
  • observability
• ordering expectation: per-offer sequence where meaningful

offer.integrity.blocked

• class: domain/governance event channel
• producer: offer integrity contour
• primary consumers:
  • publication contour
  • operator/governance surfaces
  • alerting/incident contour
• retention expectation: high enough for operational review

offer.publication.allowed / offer.publication.suppressed

• class: integration/domain hybrid
• producer: publication gating contour
• primary consumers:
  • search projections
  • external surface readiness contour
  • observability
• replay expectation: high for projection rebuilds

Main Work / Job Channels

job.offer.materialize

• producer: canonical change consumer
• consumer: offer worker runtime
• retry expectation: yes

job.offer.projection.rebuild

• producer: projection control contour
• consumer: projection runtime
• replay expectation: strong
• special note: must support bounded rebuild by tenant/surface/entity scope

RU-4 Commercial And Quote

Main Domain Event Channels

quote.created

• class: domain event channel
• producer: quote contour
• primary consumers:
  • booking contour
  • client/agency surfaces
  • observability/support contour
• ordering expectation: per-quote lifecycle

quote.expired

• class: domain event channel
• producer: quote lifecycle runtime
• primary consumers:
  • surfaces
  • booking guard contour
  • support/diagnostics
• retention expectation: medium

quote.invalidated

• class: domain/integration hybrid
• producer: quote or publication/commercial contour
• primary consumers:
  • booking contour
  • surfaces
  • cache/projection invalidation contour
• replay expectation: high when caused by upstream correction

quote.repricing.required / quote.repriced

• class: integration/domain hybrid
• producer: commercial and quote contour
• primary consumers:
  • quote lifecycle
  • surfaces
  • booking guard contour
• special note: must never be interpreted as booking confirmation proxy

commercial.policy.changed

• class: domain/integration hybrid
• producer: commercial policy contour
• primary consumers:
  • quote generation
  • tenant configuration contour
  • observability and governance
• replay expectation: high for recalculation-sensitive paths

Main Work / Job Channels

job.quote.expiry.check

• producer: scheduled worker contour
• consumer: quote lifecycle runtime
• retry expectation: yes

job.quote.refresh

• producer: quote lifecycle or surface-triggered orchestration
• consumer: commercial/quote runtime
• retry expectation: bounded, with clear invalidation behavior if exhausted

RU-5 Booking Commit

Main Domain Event Channels

booking.intent.created

• class: domain event channel
• producer: booking contour
• primary consumers:
  • confirmation follow-up contour
  • observability/support contour
• ordering expectation: per-booking journey

booking.confirmation.pending

• class: integration/domain hybrid
• producer: booking confirmation orchestration
• primary consumers:
  • support/operator surfaces
  • observability/incident contour

booking.confirmed

• class: domain event channel
• producer: booking truth contour
• primary consumers:
  • post-booking contour
  • settlement/clearing contour
  • external/internal surfaces
• ordering expectation: strong per-booking ordering
• retention expectation: high

booking.partially.failed

• class: domain/incident hybrid
• producer: booking contour
• primary consumers:
  • support/operator contour
  • incident/observability contour
  • recovery orchestration

booking.unknown.external.state

• class: domain/operational hybrid
• producer: booking follow-up contour
• primary consumers:
  • operator surfaces
  • incident contour
  • recovery jobs
• special note: must not be hidden from support-facing operational truth

Main Work / Job Channels

job.booking.confirmation.poll

• producer: booking orchestration
• consumer: booking follow-up worker runtime
• retry expectation: yes, bounded with escalation
• scheduling expectation: delay-capable

job.booking.recovery.recheck

• producer: incident/recovery contour
• consumer: booking recovery runtime
• retry expectation: bounded
• special note: should feed observability and incident state, not run silently

RU-6 Post-Booking And Clearing

Main Domain Event Channels

postbooking.change.requested

• class: domain event channel
• producer: post-booking case contour
• primary consumers:
  • support/service runtime
  • supplier interaction contour
  • surfaces where allowed

postbooking.support.case.opened

• class: domain/operational hybrid
• producer: post-booking/support contour
• primary consumers:
  • operator/support surfaces
  • SLA/escalation contour

settlement.event.posted

• class: financial domain event channel
• producer: settlement contour
• primary consumers:
  • reconciliation contour
  • finance/clearing contour
  • observability/finance operations
• ordering expectation: per-booking or per-financial-stream ordering where relevant
• retention expectation: high

reconciliation.case.opened

• class: financial/governance hybrid
• producer: reconciliation contour
• primary consumers:
  • finance operations
  • support/dispute contour
  • observability

clearing.hold.created / clearing.balance.blocked

• class: financial control signal
• producer: clearing contour
• primary consumers:
  • booking guard contour
  • tenant/partner surfaces where allowed
  • finance operations
• special note: these signals must affect admissibility decisions, not just dashboards

Main Work / Job Channels

job.reconciliation.recompute

• producer: finance/reconciliation contour
• consumer: reconciliation worker runtime
• retry expectation: yes
• replay expectation: strong

job.postbooking.followup

• producer: support/post-booking contour
• consumer: post-booking worker runtime
• scheduling expectation: yes
• special note: should respect SLA and escalation timing

RU-7 Controlled External Surface

Main Integration Channels

tenant.policy.changed

• class: integration/domain hybrid
• producer: tenant configuration contour
• primary consumers:
  • surface enablement contour
  • usage governance contour
  • projections where tenant filtering matters

tenant.surface.restricted

• class: integration signal
• producer: tenant governance contour
• primary consumers:
  • external access layer
  • support/operator surfaces

usage.quota.nearing_limit

• class: integration signal
• producer: metering and usage governance contour
• primary consumers:
  • partner-facing notifications where appropriate
  • operator surfaces
  • throttling/policy contour

usage.quota.exhausted / usage.profile.degraded

• class: integration/control signal
• producer: usage governance contour
• primary consumers:
  • access gateway / external surface policy layer
  • support and partner success contour
• special note: must have consistent relation to external error semantics

Main Work / Job Channels

job.usage.aggregate

• producer: metering scheduler/runtime
• consumer: usage aggregation worker
• scheduling expectation: periodic

job.webhook.deliver

• producer: external notification orchestration
• consumer: webhook delivery runtime
• retry expectation: yes, bounded with DLQ
• special note: should not be introduced as global baseline before webhook policy is separately stabilized

Minimal First Producer / Consumer Matrix

На первой implementation wave достаточно удерживать следующие основные producer/consumer contours:

• ingestion runtime
• governance/review contour
• canonical update contour
• offer/publication contour
• commercial/quote contour
• booking contour
• post-booking/support contour
• settlement/reconciliation/clearing contour
• tenant/usage governance contour
• projections/search contour
• observability/incident contour
• external surface control contour

Это ещё не равно окончательной runtime topology, но уже даёт bounded ownership map.

What Must Stay Out Of This First Catalog

Пока не нужно:

• описывать every internal broker topic or queue name as immutable final truth;
• фиксировать vendor-specific partitions/consumer groups;
• обещать all partner-facing webhooks;
• детализировать payload schema for every event family;
• считать этот draft substitute for full AsyncAPI package.

Что Должно Появиться Следом

Следующий практический слой после этого документа:

• Payload Family Outlines For High-Value Channels — Первые bounded payload shapes для ключевых async channels
• payload-family outlines for high-value channel families;
• payload examples for top critical event families;
• webhook policy and external async notification boundaries;
• retry/DLQ/replay matrix by channel class;
• first incident playbook mapping against these channel families.

Этот документ переводит async architecture из общего skeleton-level в первый operationally useful catalog draft.

Уточнение под Фазы 4–6 (28.04.2026) — каноничные channel families per новые домены

Документ опубликован 24.04.2026 (Фаза 3). После Фаз 4–6 опубликованы новые domain channels.

Новые каноничные channels per домен

• Payment channels: payment.intent.*, payment.refund.*, payment.chargeback.*, payment.settlement.* → reference/payment-domain.md;
• Booking state channels: 14 каноничных state transitions → reference/booking-state-machine.md;
• Tour Builder saga channels: tour.composition.*, tour.booking_transaction.*, tour.drift.* → reference/tour-builder-operational-model.md;
• Notification channels: notification.event.*, webhook.delivery.*, notification.consent.* → reference/notification-and-communication.md;
• Search channels: search.executed, search.projection_rebuilt → reference/search-and-discovery.md;
• A/B channels: experiment.*, feature_flag.* → reference/ab-testing-platform.md;
• Tenant isolation channels: isolation.check.*, cross_tenant.access.* → reference/multi-tenant-isolation-strength.md;
• Audit / security channels: отдельный класс, immutable WORM → reference/security-architecture.md;
• DR / capacity / SLA / incident channels: → operations/disaster-recovery-and-capacity.md, operations/sla-and-on-call-model.md, operations/runbooks-incident-playbooks.md;
• Compliance channels: compliance.dsr.*, compliance.consent.*, compliance.breach.* → reference/compliance-and-legal.md.

Полный сводный каталог — reference/initial-event-taxonomy.md.

При создании channel catalog для конкретного release unit — использовать каноничные имена из специализированных источников.

Уточнение выполнено через no-destruction.