System Design (Day - 7)

Pub-Sub Model (Publisher - Subscriber), Event Driver Services
Asynchronous events: We have a Microservice architecture, in that we have 5 servers in it, Let’s say the server 1 sends a request to server 2 and 3 asynchronously and waits for the response, the server 2 will do some calculations and returns the response to the server 1, but wait in server 3 after doing some calculations it has to call the server 4 and 5 with the calculated result asynchronously, and server 4 and 5 receives the request and it process the data and return that to the server 3, wait what but server 1 is still waiting for the server 3 to give response, too much latency for giving response, because we are making the http calls to the individual services, so it’ll take some time to process and give the response back to the server 1, that’s not actually good,
another scenario, let’s say server 5 fails, then the server 3 waits and sent the timeout message to the server 1, and the server 1 will send that timeout to the client, who’s calling the server 1. that’s actually not at all,
there will be data inconsistency also in the database.
What’s the solution
Publisher / Subscriber model: In this model the server 1 will send the message through broker to server 2 and 3, and tells the client that i have sent the message, in that one the message broken may be Kafka, rabbitMQ, amazonMQ, etc… and the server 2 will receive the data, if that server is down then the message will be there till that server 2 turns up, server 3 will also receive that data and it’ll process that data and through the message broker it’ll send the message to the server 3 and 4, here also same if the server is down then the message will be there till the server receives that message.
Here server 1 is the publisher and server 2 and 3 are subscribers for server 1, but server 3 is a publisher for server 4 and 5, server 4 and 5 are subscribers.
Advantages
1. There is no dependency with the each server, everything is decoupled through the message broker, server 1 will do like it published to the message broken and it relieved, and it sends a message to the client that, im successfully sent the message to the servers.
2. it simplifies everything by decoupling the dependencies and before this changes it’ll be like multiple point of failure occur if any server fails but in this model only single point of failure occur, so that we can identify the problem easily and efficiently.
3. It can be easily scalable like, let’s say we have new service running in the server 6 if this server 6 wants that server 1’s message broker data then we need to register this server 6 in that message broker then we’ll receive that message in the server 6 also, simple right.
Disadvantages
1. Data Inconsistency is the major problem in this Pub/Sub model, because the data is not in consistent with each other in the individual servers.
2. Uni-directional communication: the subscriber don’t provide feed back to the published about the delivery of the message to the subscriber
3. Increases complexity for the simple systems.
Subscribe to my newsletter
Read articles from Manoj Kumar directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by
