You are here
Home >

You have two microservices that need to communicate with each other without holding up a thread on either end. One service will receive an ID and return a message once the job is complete.

Which communication framework should be used? Choose one answer:

A) Have a shared database that allows both applications to read and write to the tables to share the data instead of having to communicate

B) Create a third service to handle the interaction between the services

C) Use asynchronous messaging to send and receive messages between each microservice 

D) Use a RESTful architecture for both, send the ID through a POST, and ping the service with a GET until a response is available

E) Abandon the microservice architecture so no interaction is needed 

Ans. C) Use asynchronous messaging to send and receive messages between each microservice

Explanation:

Using asynchronous messaging allows microservices to communicate without blocking threads. In this scenario, one service sends an ID to the other service, which processes the job and returns a message once the job is complete. Asynchronous messaging is particularly well-suited for this type of communication because it decouples the services, allowing them to operate independently and handle messages as they become available.

Asynchronous messaging is the most suitable option because it allows for decoupled communication between microservices. Here’s how it works:

  1. Sending Service: The service sends a message containing the ID to a message queue.
  2. Message Queue: The message queue stores the message temporarily.
  3. Receiving Service: A separate service (often a message broker) listens to the queue and delivers the message to the receiving microservice.
  4. Processing and Response: The receiving microservice processes the job with the ID and can send a response message back to the queue (optional, depending on the implementation).

This approach has several advantages:

  • Decoupling: Services are not directly connected, improving scalability and maintainability.
  • Non-Blocking: The sending service doesn’t wait for a response, allowing it to continue processing other requests.
  • Scalability: Message queues can handle high volumes of messages efficiently.
  • Flexibility: Asynchronous messaging allows for different response mechanisms depending on the use case.

Therefore, asynchronous messaging is the best choice for communication between microservices that need to exchange information without blocking each other’s threads.

Why Other Options Are Not Correct:

Here’s why the other options are not ideal:

A) Have a shared database that allows both applications to read and write to the tables to share the data instead of having to communicate:

  • Since this approach enables data sharing, it tightly couples the services and can lead to issues with data consistency, scalability, and maintainability.

B) Create a third service to handle the interaction between the services:

  • Adding a third service introduces unnecessary complexity and does not inherently solve the problem of non-blocking communication.

D) Use a RESTful architecture for both, send the ID through a POST, and ping the service with a GET until a response is available:

  • This polling approach is inefficient as it involves continuously pinging the service, which can lead to increased latency and resource usage.

E) Abandon the microservice architecture so no interaction is needed:

  • This is an extreme and impractical solution. The microservice architecture offers many benefits, including scalability and independent deployment, which should not be abandoned simply to avoid inter-service communication.

Top