What is the Publisher Subscriber Model?

Summary

The video script discusses the concept of event-driven services using a microservice architecture. It explains the drawbacks of a synchronous request-response model and introduces the publisher-subscriber model as a solution to decouple services. The model offers advantages like reduced dependencies, easier system understanding, and scalability. However, it also presents challenges, such as lack of transactional guarantees and potential for inconsistency in critical systems like finance. The script uses a financial transaction example to illustrate these points and highlights the importance of considering both the benefits and limitations of event-driven architectures.

Takeaways

• 😀 Microservices in the architecture include SS one, SS zero, S two, SS three, and S four, with client interactions primarily with SS one.
• 🔄 Asynchronous messaging is crucial for services like SS zero and S two, where the order of message reception does not matter.
• 🔗 The traditional request-response model can lead to services like S two waiting for responses from SS three and S four, which can cause delays and failures.
• 🚫 Request-response architecture can result in stale data and duplicate changes if a service like S four fails and the request needs to be resent.
• 📢 The publisher-subscriber model is an alternative that removes dependency on request and response, allowing for 'fire and forget' messaging.
• 🔄 With a message broker like Kafka or RabbitMQ, SS one can publish messages and be relieved of responsibility, leaving message delivery to the broker.
• 🔗 Decoupling responsibilities in the publisher-subscriber model simplifies the system, as services like SS one only need to publish to the broker.
• 🛡 The message broker provides persistence and ensures that messages are not lost, offering at-least-once delivery guarantees.
• ➕ Scalability is enhanced as new services can easily subscribe to messages from existing services without altering the publisher's code.
• 💡 The model offers a simplified interface for developers, who can send generic messages to the broker, abstracting away specific consumer needs.
• 🚨 However, the model may not be suitable for mission-critical systems that require strong consistency and atomic transactions, as seen in financial systems.
• 🔄 The lack of idempotency in message handling can lead to issues like double deductions in financial transactions if messages are resent after failures.

Q & A

What is the main focus of the discussion in the provided video script?

The main focus of the discussion is on event-driven services within a microservice architecture, specifically the comparison between a request-response model and a publisher-subscriber model.

What are the services mentioned in the script denoted by SS one, S zero, S two, SS three, and S four?

These are identifiers for different microservices within the architecture being discussed. The exact nature of each service is not specified, but they are part of a system where messages are sent between them as part of processing requests.

Why is the order of messages sent from SS one to S zero and S two not important?

The order is not important because the system is designed to handle messages asynchronously, meaning that either service can receive and process the message first without affecting the overall outcome.

What is the main drawback of using a request-response architecture in the scenario described?

The main drawback is that services like S two might be waiting for responses from both SS three and S four, which can lead to timeouts and delays in processing, especially if one of the services fails.

How does the publisher-subscriber model address the issues with the request-response architecture?

The publisher-subscriber model uses a message broker to decouple the services. Messages are sent 'fire and forget,' meaning the sender does not wait for a response, thus reducing the risk of timeouts and delays.

What are some advantages of using a publisher-subscriber model in a microservice architecture?

Advantages include decoupling of responsibilities, easier system understanding, a single point of failure, simplified interface for developers, transaction guarantees, and scalability.

What is the 'at least once' delivery guarantee provided by the message broker in the publisher-subscriber model?

The 'at least once' delivery guarantee means that if a message is sent to the message broker, it will ensure that the message will eventually reach its intended recipient, even if it requires re-sending due to failures.

What is a potential drawback of the publisher-subscriber model when it comes to financial systems?

A potential drawback is the lack of consistency and atomicity in transactions. For example, if a fund transfer service fails after a commission is deducted but before the transfer is made, it can lead to incorrect account balances and failed transactions.

How can the lack of idempotency in the publisher-subscriber model cause issues?

If a message is not idempotent, a failure in the system could lead to the message being resent, causing actions to be performed multiple times, such as multiple deductions from an account, leading to incorrect states.

What is the importance of request IDs in ensuring idempotency in message-based communication?

Request IDs are important for idempotency because they allow services to recognize and ignore duplicate messages. If a service has already processed a message with a specific request ID, it can safely ignore subsequent messages with the same ID.

Can the publisher-subscriber model be used for mission-critical systems?

While the publisher-subscriber model can be used for many types of systems, it may not be suitable for mission-critical systems where absolute consistency and atomicity are required, due to the potential for message duplication and lack of transactional guarantees.

What is an example of a real-world application where the publisher-subscriber model is effectively used?

An example is Twitter, where the model is used for posting tweets (events) and having multiple subscribers (users) consume those events, making it ideal for handling high volumes of distributed messages.