Brokers

Brokers are concrete messaging substrates that mediate delivery between producers and consumers.

Examples include queues, topics, streams, pub/sub systems, event buses, and log-based messaging systems.

Brokers can realize interaction patterns such as:

Queue delivery.
Pub/sub.
Stream subscription.
Broadcast or fanout.
Retained or replayable delivery.
Dead-letter or retry paths.

A broker message is a transport record or carrier. Emission, broker admission, delivery, and receiving-boundary ingress are distinct occurrences; ingress is an exogenous event for the receiving observer. The message contract may explicitly express event, request, signal, reply, command, or acknowledgment intent and thereby make an interpretation expected. The corresponding semantic or protocol role is still established relative to the modeled effect, emitter obligation, receiver interpretation, and boundary. One broker can carry several roles, and one role can be realized without a broker.

When a broker carries canonical emission envelopes, it should preserve or convey the required stable emission and contract identity, payload revision, correlation, causation, tenant or authority scope, idempotency basis, ordering key, response obligation, and provenance. Broker-assigned message, partition, offset, delivery, and acknowledgment identifiers remain substrate identities and do not replace the semantic ones.

Broker guarantees must be interpreted through the model's delivery semantics. Ordering, durability, deduplication, acknowledgment, replay, progress, and settlement are always scoped to the broker's own boundaries and keys. A replay cursor, provider delivery identity, current settlement authority, application checkpoint, and settlement receipt remain different evidence even when one SDK exposes them through adjacent operations.

A brokered messaging channel is normally realized by more than one network channel: producers interact with broker endpoints, broker state mediates the exchange, and consumers interact through later or concurrent sessions. Broker protocol acknowledgments and flow control compose with transport acknowledgments and receive windows but do not inherit their meanings. Conversely, one broker connection may multiplex many topics, subscriptions, partitions, and logical channel directions.

At its public ports, a broker queue commonly behaves as a passive sink for active producers and a passive source for active consumers. It therefore separates producer and consumer cadence and changes the interaction-control driver across the queue. Push subscriptions, event routers, and managed pipes may expose other roles, often by combining internal queues with active drivers. Public push or pull behavior, internal scheduling, buffering, batching, ordering, and backpressure should be modeled separately.

Broker delivery does not by itself provide durable wait arbitration, exclusive signal consumption, entity concurrency control, request-result admission, external idempotency, or exactly-once logical consequences. Those guarantees may be composed with inbox, outbox, checkpoint, claim, fence, and operation-ledger mechanisms when the composition has explicit evidence.

Formal relations

may_realize: Interaction Channels — Mediates logical delivery paths when framing, endpoint attachment, topology, identity, ordering, acknowledgment, and recovery requirements are preserved.

External References

Gregor Hohpe and Bobby Woolf, Message Channel, Point-to-Point Channel, Publish-Subscribe Channel, and Message Bus, Enterprise Integration Patterns, 2003.
Gregor Hohpe, Control Flow—The Other Half of Integration Patterns, 2024.