Publisher-Subscriber services publish events through a channel as messages. Multiple interested consumers listen to the events by subscribing to these channels.
“Services rarely live in isolation. The platform grows and services proliferate. We need services to interact without creating interdependency.
&&&&
Asynchronous messaging enables services to announce events to multiple interested consumers without coupling.”
In the example, the Posts service will publish an event when a post is created in the application.
The Feed service is listening to postCreated events. It will take the posts and send to the feed.
The Leaderboard service will receive the same event and will update the leaderboard for the top posts and contributors.
The Recommendations service will keep track of who is posting what, things that seem to go great together, and which is the next method you should try.
Services are decoupled. They work together by observing and reacting to the environment, and each other — like rappers freestyling.
When new services and features are available they can subscribe, get events, and evolve independently.
Teams can focus on delivering value improving their core capabilities, without having to be focused on the complexity of the platform as a whole.
Publisher / Subscriber is a great match for event-driven architectures. With lots of different options for messaging: SNS, Kinesis, Azure’s Service Bus, Google’s Cloud Pub/Sub, Kafka, Pulsar, etc. These messaging services will take care of the infrastructure part of pub/sub, but given the asynchronous nature of messaging all the issues discussed previously — message ordering, duplication, expiration, idempotency, and eventual consistency, should be considered in the implementation.
