Skip to content

Latest commit

 

History

History
36 lines (25 loc) · 2.51 KB

3010-services-communication.md

File metadata and controls

36 lines (25 loc) · 2.51 KB
Raw

Services Communication Pattern

Context

The microservices within the system need to communicate with each other in order to achieve the desired functionality. The communication between microservices is crucial for achieving scalability, fault tolerance, and maintaining loose coupling.

Decision

We will use messaging to facilitate communication between microservices. The message broker will be responsible for receiving messages from the microservices and distributing them to the appropriate microservices. The message broker will also be responsible for ensuring that the messages are delivered to the microservices.

Rationale

This decision is based on the following factors:

Asynchronous Communication:

Asynchronous communication (messaging) is crucial for handling tasks that may take varying amounts of time to complete. This allows services to continue their work without waiting for a response from the receiving service, leading to better overall system performance.

Loose Coupling:

Messaging promotes loose coupling between microservices. Services interact with each other by placing messages in the queue, and the recipient service consumes messages when it is ready. This allows services to be deployed and updated independently, as long as the message structure remains compatible.

Scalability:

Messaging facilitates scalability by distributing workloads across multiple instances of a microservice. New instances can be added to handle an increasing number of messages in the queue, providing a straightforward path to scaling our services.

Error Handling and Resilience:

Messaging allows us to implement robust error handling and retry mechanisms. Messages can be reprocessed or moved to a dead-letter queue in case of processing failures. This enhances the resilience of the system.

Decoupled Release Cycles:

Using messaging makes it easier to deploy and update microservices independently. Changes in one microservice do not necessarily impact the others, as long as the message structure remains compatible.

Consequences:

The decision to use messaging as the communication pattern between microservices has several consequences:

  • Development teams will need to implement message producers and consumers.
  • We will require a reliable and scalable message broker or queue service.
  • Contracts and protocols for communication between microservices will need to be standardized.
  • Monitoring and management of the message queue infrastructure will be necessary to ensure reliable operation.

Status:

Approved