Publish / Subscribe

Let's understand each component of the Pub/Sub architecture:

💻 Client

Sends requests to the Publisher Server (e.g. creating a new post or making a purchase).

🖥️ Publisher Server

Receives user requests and publishes the event to the Pub/Sub Broker (e.g., publishing an order.created event).

📡 Pub/Sub Broker

The event router (like Redis Pub/Sub, Kafka, or AWS SNS). It manages channels/topics and delivers published messages to all subscribed services.

🖥️ Email & Analytics Services

Decoupled subscriber microservices. They subscribe to specific channels on the broker. When an event is published, the broker pushes the message to all of them concurrently.

Unlike a Message Queue where only one consumer handles each message, a Pub/Sub Broker implements fanout delivery, where every subscriber receives a copy of the message.

Why Use Pub/Sub?

- Extreme Decoupling: The Publisher Server does not know who the subscribers are. If you want to add a new SMS notification service, you just connect it to the broker. You don't need to change any code in the Publisher Server.

- Parallel Event Processing: When a user registers, the Email Service sends a welcome email and the Analytics Service logs the user signup *simultaneously* in parallel.

Watch It in Action

Press Play. You'll see the publisher server post an event to the broker. The broker immediately sends an ACK back to the publisher, and concurrently fans out the message to both Email and Analytics services at the exact same timestamp!