- So, as we know, cloud-native applications consist of a collection of microservices that interact with each other, as well as with external systems, through interservice communication techniques.
- With the proliferation of microservices and ever-growing business requirements, establishing reliable communication between microservices in cloud-native applications has become one of the most challenging aspects.
- Our goal is to demystify these concepts by creating robust connections using a common framework, following best patterns not only within microservices but also with external services.
- Primarily, we’ll focus on synchronous and asynchronous communication.
- In **synchronous communication**, one microservice invokes another and expects a response within a specific timeframe. This type of communication often uses patterns such as Request-Response and Remote Procedure Calls (RPC).
- For **asynchronous communication**, microservices communicate by passing messages asynchronously through an intermediary (known as a message broker). We implement this using patterns like queue-based messaging and publisher-subscriber messaging.
- In most cases, we end up mixing these patterns.
- When building cloud-native applications, we often find that one microservice may need to invoke one or more other microservices and wait for a timely response to complete its business logic. For this kind of microservice, we can use **synchronous messaging patterns**. In this case, the business logic of a given microservice depends on one or more other microservices or systems.
- There are many messaging patterns that can be used to build synchronous communication in a cloud-native application. One of the standard patterns is the “Request-Response” pattern.

Request-Response Pattern : 

- ntswer this pattern is the most commonly used commincation pattern in cloud natvie applications , as well as in the space of distributed computing at largze  , donc this pattern requrie both paryty create a contract and pass data between them

![image.png](https://prod-files-secure.s3.us-west-2.amazonaws.com/c26cbd8c-4ae9-4ab6-b595-99bb653f9d83/d3afc46d-19b2-47ff-a1b0-545ccde06287/image.png)

In the **Request-Response pattern**, one microservice (acting as the client) sends a request to another microservice or system (acting as the server). The client expects to receive a response to complete its operation.

- The client sends the request and **waits** for the response.
- During this waiting period, the client is **blocked** (i.e., it cannot proceed with any other work until it receives the response).
- The communication channel between the client and the server **remains open** while the client is waiting for the response. This ensures that the client can receive the response once it's ready.

This pattern is often used for operations where the client needs an immediate response to proceed with its business logic. However, this blocking nature can introduce latency, and if the server is slow or unavailable, it can negatively impact the client’s performance.

In cloud-native applications, this pattern is typically implemented using technologies such as HTTP requests, gRPC, or similar synchronous protocols, where the client makes a request to a server and is blocked until the response is returned. 

In the **Request-Response pattern**, we aim to establish a connection between the client and the server (microservice) to exchange data in a synchronous manner. This data exchange is known as a **message**. Once the connection is established, the client sends a request for data to the microservice and waits until either:

- It receives the response data, or
- The maximum time the client intends to wait is reached (known as a **timeout**).

Q- now let’s move to hands on Tutor using two seperate micrtoserce each one with deffrente buissines logic but have a depencies neeet to espblish a request - resonse syschnose commincatinn

- stack : spring boot , spring cloud  , github action , docker (if need it )

Q- we need to build to build proof of concept in the context of e-commerce microce archire 

Q- give me fitst the roadmap okii 

to how to implement his