Skip to content

Topic Brokered Event Distribution

Route producer emissions through named topics and broker-managed subscriptions so consumers receive relevant events without producers needing to know who listens.

One-line summary

Route producer emissions through named topics and broker-managed subscriptions so consumers receive relevant events without producers needing to know who listens.

Disposition check result

publish_subscribe is drafted as a distinct full archetype. It is merge-sensitive with message_mediated_state_coordination, but the queue-generated parent message-passing draft explicitly reserved anonymous brokered topic subscription for a separate neighboring treatment. The accepted corpus did not already contain a publish-subscribe archetype, alias, component, mechanism, or duplicate-map entry.

Core intervention

Create a governed publish-subscribe channel by defining a topic namespace, publisher authority, event message contracts, broker responsibilities, subscription registry, filter and authorization rules, delivery and replay semantics, subscriber handler obligations, lifecycle controls, observability, and broker compromise safeguards.

Boundary note

This draft should not be collapsed into a generic message broker, event bus, queue, hub, or gateway. Those are mechanisms or neighbors. The archetype is the complete topic/subscription/fan-out governance pattern.

Common Mechanisms

  • Access-Controlled Topic — A topic whose publish and subscribe rights are governed by an explicit access policy, so only authorized producers can emit to it and only authorized consumers can see it.
  • Consumer Group — A pool of cooperating consumers that split one subscription's event stream across partitions, so throughput scales with instances while each event is handled once within the group.
  • Content-Based Subscription Filter — Narrows what a subscriber receives by evaluating predicates on each event's content or attributes, so a subscription gets only the messages that actually match its interest.
  • Dead-Letter Queue — A side queue that captures events a subscriber cannot process after its retries are exhausted, isolating poison messages and preserving them as evidence instead of losing or looping them.
  • Delivery Acknowledgement — A per-message confirmation handshake in which the broker holds an event as delivered only once the consumer acks — redelivering on silence to make at-least-once real.
  • Durable Subscription Queue — A per-subscriber queue that persists unacknowledged events across disconnects and restarts, so a consumer that was offline still receives everything it missed.
  • Fan-Out Exchange — The broker's routing primitive that copies each published event to every subscriber queue whose topic binding matches — one publish becomes many, decided by topic pattern.
  • Message Broker — The trusted intermediary every publish and subscription passes through — it hosts topics and holds the subscription registry so producers and consumers never address each other directly.
  • Publish API or Producer SDK — Gives producers a typed, authenticated entry point for emitting events to topics, enforcing the message contract at publish time so every event on the bus is well-formed and attributable.
  • Replay Log or Event Stream — Retains published events as an ordered, append-only log so any consumer can read — or re-read — from a chosen point, turning the event history itself into a replayable source of truth.
  • Schema Registry — A managed register of event schemas and their versions that decides whether a new message format is compatible before producers and consumers ever exchange it.
  • Slow Consumer Isolation — Contains a slow or stuck subscriber so its backlog can't stall the broker or starve healthy consumers, keeping one lagging handler from becoming everyone's outage.
  • Subscription API — Lets consumers register, adjust, and retire their own subscriptions through a self-serve interface, recording each in the subscription registry and governing its lifecycle.
  • Subscription Health Dashboard — Surfaces per-subscription delivery health — lag, error rate, retries, relevance — so operators can see which subscribers are keeping up and which are silently falling behind.
  • Topic Catalog — A browsable, governed directory of the topics that exist — their meaning, owner, and schema — so teams discover and reuse the right topic instead of inventing a duplicate.
  • Topic Exchange or Event Bus — The routing core that matches each published event's topic against subscription bindings and delivers a copy to every matching subscriber, without producer and consumer ever naming each other.
  • Transactional Outbox — Captures an event in the same local transaction as the state change that caused it, so a committed change is never published without its event and an event is never published without its change.
  • Webhook Subscription — Delivers a subscriber's matching events by calling its own HTTPS endpoint — a signed, retried HTTP callback — so an external system can subscribe without ever holding a broker connection.

Compression statement

Topic-Brokered Event Distribution is the pattern of replacing direct sender-recipient coupling with a topic namespace, a broker or routing layer, and subscriber-owned consumption contracts. Producers publish event messages to topics; consumers declare subscriptions, filters, delivery preferences, and handler obligations; the broker validates, routes, fans out, buffers, replays, throttles, expires, and observes the resulting deliveries while preserving boundaries between producer state, broker responsibility, and subscriber state.

Canonical formula: publishers + topic_namespace + broker_subscription_registry + fanout_delivery_semantics + subscriber_handlers -> decoupled_event_distribution

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (7)

  • Channel: A bounded conduit between source and receiver whose capacity, alphabet, and noise profile are constitutive of what can cross it — a fact outside the channel's bandwidth, codebook, or noise floor is structurally inexpressible through it.
  • Coordination: Aligning independently controlled actors so their separate actions combine into a coherent collective outcome despite distributed decision-making and incomplete shared information.
  • Coupling: Interdependence among subsystems.
  • Indirection: Introduces intermediary references.
  • Message Passing: Autonomous holders of private state interact only through discrete addressed messages over intermediating channels.
  • Publish Subscribe: Producers emit to a topic and consumers subscribe to the topic, routed by an anonymous broker.
  • Queueing: Organizes tasks into a waiting line based on arrival and service rates.

Also references 18 related abstractions

  • Access Control: Restrict system access.
  • Accountability: Responsibility for actions.
  • Backpressure: A return signal from a downstream stage throttles upstream production to its own capacity, converting a one-way push into a two-way conversation that holds the system at the bottleneck's throughput instead of accumulating hidden queue debt.
  • Boundary: Defines system limits.
  • Channel Capacity: Any information-bearing medium has a hard upper bound on reliable throughput that effort cannot exceed.
  • Embedding: A structure-preserving injection of one system faithfully into a richer one.
  • Event-Centered Modeling: Making events the primary nodes through which entities, places, and periods are connected, so that everything else is derived as a projection of the event log.
  • Eventual Consistency: Distributed copies of shared state are allowed to diverge under local updates, with a deterministic merge guaranteeing they reconverge once updates stop.
  • Information Asymmetry: Parties to an interaction hold unequal private knowledge.
  • Information Hiding: Deliberately concealing internal facts behind a stable public surface to control dependencies.

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Notification Pub/Sub · communication variant · recognized

Producers publish notifications to topics that subscribers receive for awareness or action.

  • Distinct from parent: It is a lower-durability, notification-centered subtype of the broader topic-brokered distribution pattern.
  • Use when: Events are lightweight alerts or notices; Missed delivery is tolerable or separately recoverable; Subscribers need independence from producer recipient lists.
  • Typical domains: user notification systems, operations alerting
  • Common mechanisms: topic exchange or event bus, webhook subscription, delivery acknowledgement

Durable Event Stream Subscription · implementation variant · recognized

Published events are retained so subscribers can replay, backfill, or resume from an offset.

  • Distinct from parent: It strengthens persistence, ordering, replay, and compatibility requirements.
  • Use when: Events are part of system state reconstruction; New subscribers need historical backfill; Outages should not lose events.
  • Typical domains: data streaming, audit logging
  • Common mechanisms: replay log or event stream, schema registry, consumer group

Content-Based Pub/Sub Routing · implementation variant · recognized

Subscribers receive events based on attributes or predicates inside the event, not just the topic name.

  • Distinct from parent: It emphasizes predicate routing over simple topic membership.
  • Use when: Topic-only routing is too coarse; Subscribers need narrow criteria; Event attributes can be trusted and indexed.
  • Typical domains: market data, iot
  • Common mechanisms: content based subscription filter, access controlled topic

Webhook Pub/Sub · implementation variant · recognized

Subscribers register endpoints that receive topic events as outbound callbacks.

  • Distinct from parent: It is a concrete external-integration delivery form with endpoint security and retry concerns.
  • Use when: External consumers need event delivery without polling; Subscriber endpoints can be authenticated and monitored; Retry and signature verification are required.
  • Typical domains: saas integration, payment events
  • Common mechanisms: webhook subscription, delivery acknowledgement, dead letter queue

Near names: Pub/Sub, PubSub, Publish Subscribe, Brokered Topic Router, Event Bus.