...

/

Introduction to the Pub-Sub Service

Introduction to the Pub-Sub Service

Learn the inner structure of the pub-sub system.

Motivation

In today's era, systems are designed by following the microservices architecture in which multiple services interact to perform a specific task. A microservice architecture needs the interconnectivity and interoperability of different subsystems. Communication between the subsystems can be performed either synchronouslyA service waits for another service to complete the request and then performs the required operation. or asynchronously.A client, while requesting a service, does not wait for or expect an immediate response and can start doing something else. When a response is ready, it is sent to the service.

Asynchronous communication benefits us the most in the microservice architecture because services generally do not wait for a response. Nevertheless, a decoupling layer between services is required to enable them to communicate and perform tasks asynchronously.

In the following section, we’ll answer some important questions, such as what happens if the services depend on each other for data processing and how to make communication possible between them. Let's start by highlighting challenges in a request-response architecture that can lead to opting for event-driven architectures.

Request-response model

Most client-server communication follows the request-response model using HTTP with synchronous communication. Once the client initiates the request, the server responds with content after performing all the required operations. Let's look at the video file upload service in the YouTube service to understand the request-response model.

Press + to interact
Request-response structure with synchronous services awaiting responses
Request-response structure with synchronous services awaiting responses

The client initiates a request to upload the video file. The API gateway sends the request to the upload service, which routes the request to other services, such as the processing and notification services. In the whole procedure, the client waits for the success or failure status until the entire process is completed. Until then, the client can keep working on something else and check if the response is received.

In case of successful execution or failure, the response is sent back via the previous service in the path toward the client, as shown below:

Press + to interact
Request-response structure with synchronous services having failure status
Request-response structure with synchronous services having failure status

Challenges

An application with request-response architecture becomes challenging in the following scenarios:

  • Consider a situation where the upload and processing services complete their task successfully, but the notification ...