The Publish-Subscribe pattern (Pub/Sub) allows for the decoupling of message senders and receivers. It is used in distributed systems where asynchronous communication mechanisms are required. Pub/Sub enhances scalability and flexibility in 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.
Publish-subscribe is an asynchronous communication pattern in which senders publish messages under a topic and receivers subscribe to that topic.
The pattern emerged from decoupled messaging and event systems. Brokers such as Kafka, Google Cloud Pub/Sub, and RabbitMQ implement it with different delivery, storage, acknowledgement, and scaling models.
Publishers do not know subscribers; they write events or messages to a topic. The broker distributes them, while processing, retry, and ordering remain operational concerns for consumers.
Senders and receivers can be developed and scaled independently.
Acknowledgement, retries, ordering, and delivery guarantees depend on the broker.
Subscribers choose topics or filters and process messages published there.
Pub/sub suits event distribution, integrations, and asynchronous processing with multiple receivers. Message contracts, idempotency, failure handling, and observability require deliberate design.
Where this building block is located in the topic model.
No structure path available.
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.