Publish/Subscribe

The publish-subscribe (pub-sub) pattern decouples publishers and subscribers, allowing scalable and flexible communication without direct knowledge of each other.
Publishers send messages to a topic or channel; subscribers express interest in topics and receive relevant messages.
This pattern is rooted in event-driven architecture and is fundamental in message-oriented middleware and enterprise service buses.

Early in-process implementations include Windows Forms in .NET, where different methods subscribe to events like button clicks.
Modern pub-sub systems employ a bus, broker, or topic-based channel where service A publishes messages and service B (or multiple services) subscribes to them.
Multiple subscribers (sometimes hundreds) can receive the same event, such as an order-created message.
Real-world example: IoT systems where numerous devices send data to a central topic, with multiple backend systems (e.g., analytics, control) subscribing to those events.
Popular message brokers: Apache Kafka, RabbitMQ, MQTT-based systems, and cloud services such as AWS EventBridge and SNS.

Scalability and observability become difficult as the number of publishers and subscribers increases, making it hard to trace cause and effect.
Ensuring message ordering can be complex; point-to-point integration might be better for strict order requirements.
Message durability depends on the broker—some cloud services offer no durability guarantees, requiring error handling and features like dead-letter queues.

While runtime coupling is low, schema-level coupling persists as services depend on shared message formats.
Changing message schemas can inadvertently break downstream systems unless all consumers update in lockstep.
Asynchronous integration enables team independence but may introduce issues if message formats evolve without coordination.
Information hiding and consistent public schemas can mitigate many schema evolution challenges in microservices.