Loading content
A message broker enables software applications to communicate across network protocols and exchange messages asynchronously. This promotes loose coupling and improves system architecture.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What you need to understand to reason about a domain.
A message broker accepts messages from producers, routes them to suitable consumers, and can manage delivery and decoupling.
The broker idea emerged in enterprise integration as an intermediary between independent applications. Different forms grew from that role: Kafka organizes durable event streams, RabbitMQ mediates delivery through messaging topologies, and Redis provides data structures and streams that can support messaging.
A broker is a post office: senders need not know recipients directly, and the post office routes each message according to rules.
The broker accepts messages and may validate format, authentication, or destination.
Rules assign messages to queues, topics, or consumers.
The broker controls when and with which guarantees messages are delivered.
A broker reduces direct service dependencies and centralizes delivery and operational policies.
Where this building block is located in the topic model.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.