Skip to content

25-Publisher-Subscriber-model.md

Latest commit

 

History

History
43 lines (30 loc) · 1.6 KB

25-Publisher-Subscriber-model.md

File metadata and controls

43 lines (30 loc) · 1.6 KB

Publisher-Subscriber Model (Pub-Sub)

The Pub-Sub model enables asynchronous communication between services by decoupling event producers (publishers) and event consumers (subscribers). It's commonly used in microservices architectures.

How It Works:

  • Publishers send events or messages.
  • Subscribers listen and process these events.
  • A message broker (e.g., Kafka, RabbitMQ) facilitates the communication.

Advantages:

  1. Decoupling: Services operate independently. Example: Payment service doesn’t need to know about the shipping service.
  2. Scalability: Easily add new subscribers without affecting existing ones.
  3. Fault Tolerance: Failures in one service don't impact others, thanks to the message broker.
  4. Flexibility: Publishers and subscribers can evolve independently.

Disadvantages:

  1. Increased Latency: Extra layer (message broker) can cause delays.
  2. No Strong Consistency: Not suitable for systems that need strict data consistency.
  3. Operational Overhead: Requires managing message brokers, adding complexity.

Real-World Example:

  • E-commerce:
    • Publisher: Order Service sends an event when an order is placed.
    • Subscriber: Inventory Service listens and updates stock levels.

Simple Diagram:

[Publisher Service] → [Message Broker] → [Subscriber Service]

Conclusion: The Pub-Sub model is ideal for event-driven systems, offering asynchronous communication and loose coupling, but may not be suited for highly consistent systems.