Communityv1.1

Channel Model

Map your schemas to messaging channels across any broker — Kafka topics, RabbitMQ exchanges, Redis streams, Pulsar topics, NATS subjects, and cloud services. Channels are governance objects in event7, not read from the broker.

Open Channels API Reference

Core Concepts

The Channel Model introduces an explicit, broker-agnostic layer between your schemas (in the Schema Registry) and the messaging infrastructure they travel on.

Registry (1) ─────── (N) Channel
                          │
                          │ N:N (via channel_subjects)
                          │
Registry (1) ─────── (N) Subject (= schema in the SR)

A Registry has both Subjects (from the SR) and Channels (declared in event7).
The mapping between them lives in the channel_subjects pivot table.

Channel

A named message exchange point tied to a broker and a messaging pattern. Models the producer-facing ingress, not the full broker topology.

Kafka topic, RabbitMQ exchange, NATS subject, Redis stream

Binding

The explicit N:N relationship between a channel and a subject, with a strategy, role, selector, and health status.

orders-value → orders-topic (channel_bound, value, active)

Data Layer

The maturity of the data flowing through a channel. The primary layer lives on the subject (via enrichments); the channel layer is a UX hint.

RAW → CORE → REFINED → APPLICATION

Resource Kind

The physical nature of the broker resource behind a channel. A single broker_type can have multiple resource kinds.

topic, exchange, subject, queue, stream

Messaging Patterns

Every channel has a messaging pattern that describes its communication model:

Topic Log

Ordered, persistent, append-only log. Consumers read at their own pace. Replay is possible.

OrderedPersistentReplayableConsumer groups

Kafka, Redpanda, Pulsar, Redis Streams

Pub/Sub

Publish-subscribe with routing. Messages delivered to all matching subscribers. No replay.

Fan-outRouting keysNo replayPush delivery

RabbitMQ, NATS, Google Pub/Sub

Queue

Competing consumers. Each message delivered to exactly one consumer. Load balancing built-in.

Exactly-onceFIFO optionalDead letterLoad balanced

AWS SQS, Azure Service Bus

Supported Brokers

event7 supports 9 broker types. Each maps to a default resource kind and messaging pattern:

Broker	Resource Kind	Pattern	Native SR	AsyncAPI Protocol
Kafka	topic	Topic Log	Confluent SR, Karapace, Redpanda	kafka, kafka-secure
Redpanda	topic	Topic Log	Redpanda SR	kafka
RabbitMQ	exchange	Pub/Sub	—	amqp, amqps
Pulsar	topic	Topic Log	Pulsar SR	pulsar
NATS	subject	Pub/Sub	—	nats
Google Pub/Sub	topic	Pub/Sub	—	googlepubsub
AWS SNS/SQS	queue	Queue	Glue SR	sns, sqs
Azure Service Bus	queue	Queue	Azure SR	servicebus
Redis Streams	stream	Topic Log	—	redis

Brokers without a native SR (RabbitMQ, NATS, Redis Streams, Google Pub/Sub) can use an Apicurio instance as a broker-agnostic registry. This is the foundation of the upcoming Hosted Registry feature.

Binding Strategies

The binding strategy describes the conceptual relationship between a subject and a channel — a generalization of Confluent's TopicNameStrategy / RecordNameStrategy:

Channel BoundTopicNameStrategy

1:1 coupling. The subject belongs to this specific channel. Typical for RAW layer ingestion topics.

orders-value → orders topic

Domain BoundRecordNameStrategy

N:1 decoupled. A domain schema shared across multiple channels. Typical for CORE layer canonical models.

com.acme.Order → multiple topics

App Bound

Application-specific view. A schema designed for a single consuming application. Typical for APPLICATION layer.

dashboard.OrderView → dashboard topic

The strategy is conceptual — it describes intent, not enforcement. event7 uses it for warnings (e.g. a channel_bound subject linked to 5+ channels) and UX hints, not blocking.

Data Layers

Inspired by the Schema Strategy pattern, data layers describe the maturity and purpose of data as it flows through the pipeline:

RAWCoupled to source

Raw data collected from external sources. 1:1 with the ingestion channel. No transformation, no reuse.

<topic-name>-value

COREDecoupled (domain model)

Canonical business model. Reusable across teams. Independent evolution. The backbone of your data platform.

<domain>.<entity>.<version>

REFINEDReferences Core

Aggregated and enriched data. Built from Core types. Time-windowed summaries, joined views.

<domain>.<entity>.agg.<period>

APPLICATIONDecoupled (app-specific)

Application-specific views. Optimized for a single consumer. Lightweight schemas.

<app>.<domain>.<entity>

The primary layer lives on the subject (via enrichments) — it describes the semantic maturity of the data. The layer on a channel is a UX hint derived from its bindings.

Binding Properties

Each binding (subject ↔ channel) carries metadata beyond the N:N relationship:

Property	Values	Purpose
schema_role	value, key, header, envelope	Which part of the message this schema covers
binding_strategy	channel_bound, domain_bound, app_bound	Conceptual coupling model (see above)
binding_origin	tns, trs, manual, heuristic, routing_key	How the binding was established
binding_selector	routing key, attribute filter	Sub-channel filter (RabbitMQ routing, Pub/Sub attributes)
binding_status	active, missing_subject, stale, unverified	Health of the binding (does the subject still exist?)

AsyncAPI Integration

Channels are the bridge between event7 and AsyncAPI. The integration works in both directions:

Import (Spec → event7)

·servers.*.protocol → broker_type
·channels.* → channels (address, bindings, description)
·channels.*.messages → bindings (subject ↔ channel)
·channels.*.bindings.kafka → broker_config (partitions, replicas)
·operations.*.action → messaging_pattern hint
·x-owner, x-tags, x-data-layer → enrichments
·components.schemas → match SR / register if missing

Generate (Subject → Spec)

·Schema + enrichments → AsyncAPI 3.0 spec
·Kafka bindings (topic, partitions, Magic Byte)
·Key schema auto-detection (-value → -key)
·Avro-to-JSON-Schema conversion
·Content type per format (Avro MIME, JSON)
·Examples generated from field names
·View in drawer or download YAML

Smart Schema Registration

When importing with "register schemas" enabled, event7 checks the registry type. Apicurio (broker-agnostic) accepts all schemas. Confluent-like registries only receive Kafka/Redpanda schemas — other broker schemas are skipped with a clear warning.

Broker Config (JSONB)

Each channel can store broker-specific configuration in a flexible JSONB field. Extracted automatically during AsyncAPI import:

Kafka

partitionsNumber of topic partitions

replication_factorReplica count

retention_msMessage retention in milliseconds

cleanup_policydelete, compact, or compact,delete

RabbitMQ

exchange_typetopic, direct, fanout, headers

durableSurvive broker restart

Other brokers (Pulsar, NATS, Redis, cloud services) can store any key-value pairs in broker_config. The field is extensible by design.

Quick Start

Create channels manually

Go to /channels, click "New Channel", pick a broker type, set the address. Add bindings to link subjects.

Or import from AsyncAPI

Go to /asyncapi → Import tab. Paste or upload a YAML/JSON spec. Preview, then apply. Channels, bindings, and enrichments are created in one click.

Check the Catalog

The Event Catalog now shows broker badges for each subject. Filter by broker type to find Kafka vs RabbitMQ schemas.

Generate AsyncAPI specs

Click the AsyncAPI icon on any catalog entry to generate or view a spec for that subject.

Roadmap

Channel CRUD + Bindings	✓ Available
Multi-broker support (9 broker types)	✓ Available
AsyncAPI Import (preview + apply)	✓ Available
Smart schema registration (provider-aware)	✓ Available
Data layers on channels + enrichments	✓ Available
Catalog integration (broker badges, filter)	✓ Available
Broker config JSONB (partitions, exchange type…)	✓ Available
Auto-detect TNS (heuristic from subject names)	Planned
AsyncAPI Export Mode 3 (real channels → spec)	Planned
Channel Map visualization (d3-force graph)	Planned
Hosted Registry (Apicurio for brokers without SR)	Planned
Multi-registry import routing	Planned
Channel health monitoring (lag, throughput)	Planned
Channel-level governance rules	Planned