A publish/subscribe model decouples message producers from consumers. Producers publish events without direct knowledge of subscribers, while each subscribed consumer receives and processes the message independently. section 1.4.1 section 5.2.1
Architectural consequences include:
- Producers typically publish in a fire-and-forget manner, optionally receiving delivery acknowledgment. section 1.4.1
- A message published to a Kafka topic remains available to all subscribed consumers, rather than being assigned exclusively to one consumer. section 5.2.1
- Kafka suits asynchronous, event-driven workflows but does not naturally fit request-response or point-to-point requirements. section 5.2.1 section 7.0
- Producers own the event structure, so explicit business requirements and reusable notifications support coordination and governance. section 1.4.1
Customer address updates
CustomerService stores a changed address and publishes a customer-updated event. BillingService, AnalyticalService, and OrderService subscribe independently: billing updates payment information, analytics refreshes reports, and ordering maintains accurate delivery data. If consumers need different views, a processing service can route the raw event into tailored shipping-address and billing-address topics. section 1.4.1 section 1.5.3
Figure 1.5 Publish-subscribe example: CustomerService publishes a “customer updated” event to a channel; all subscribers receive it independently.
Diagram the CustomerService publisher, a channel, and multiple subscribers receiving the customer-updated event independently. section 1.4.1
