Align the Communication Style to the Business Process

Context

Microservices are being adopted. A domain analysis uncovered that business processes are synchronous and/or asynchronous. The workflow design aligns with the business processes.

Problem

• Using synchronous communication technologies to emulate an asynchronous workflows introduces undesired complexity and vice versa.

Solution

Align the communication technology with the nature of the underlying workflow. This approach bypasses the complexity added by emulating a synchronous workflows by an asynchronous technology and vice versa.

For synchronous workflows, HTTP to facilitate request-response communication is a widely adopted communication protocol. For asynchronous workflows, publish-subscribe or message-oriented middleware like RabbitMQ is widely adopted. Apache Kafka can also be adopted for similar means acting more like a data mesh.

Make sure the workflow strategy of the system is aligned to the kind of business flows. Otherwise there might be additional complexity involved. If the workflows follow a choreography-based approach the communication technology should support for its asynchrous nature, e.g. by choosing a messaging system as a message broker or a publish-subscribe mechanism. If the workflow follows an orchestration-based approach the communication support for that usual synchronous nature, e.g. by choosing HTTP as communication protocol.

Implementing synchronous and asynchronous workflows might lead to introducing synchronous and asynchronous communication technologies in parallel. As an alternative to this technique, one might decide to go for one stringent solution in favor of not adding complexity by different communication technologies but introducing the complexity by emulating a not matching workflow.

Example

The emulation of a synchronous workflow via asynchronous messaging adds complexity to the system's design. Responses need to be matched to their request, and - in scaling scarios with multiple replicas - be routed back to the original requesting instance. Further, the requesting instance can already be unavailable.

To avoid this complexity, facilitate synchronous communication techologies:

Maturity

More data required (only 2 sources).

Sources of Evidence

Interview D:

• Adjust technical communication style to the domain comm. style
• makes it easier
• no undesired complexity by emulating with technical means the domain communication
  • stay within the right pattern right away
• trade-off: one vs. multiple communication styles
  • increase complexity by multiple vs. stringency sticking with one
  • tendency: align over stringency
  • but it's gray, not black-white
• => possibility of mixing different comm. styles within system

Interview F:

• Use case plays a role to decide sync vs. async communicaiton between microservices
• If user in front of monitor and needs feedback => synchronous
  • UI where milliseconds play a role
• If I have a procedure that needs to be completed before moving on => synchronous sequence
  • easier if done synchronously
  • possible to solve async, but more copmlex
• If something not time critical => async
  • e.g., reporting
  • a few seconds earlier or later doesn't play a role as long as the report is there in the next morning
  • in case of CQRS

Code "Collection: Potentially multiple communication styles"

This code is an implication if there are different comm. styles on the domain level. The excerpts are indications that systems can use different communication styles. However, they give no evidence that this heterogeneity is grounded in the different communication styles on domain level

LN21:

• Microservice systems may not only use REST invocations and message queues but also remote procedure calls and socket communication

LN48:

• Example system where Registration microservice uses REST APIs and Newsfeed microservice uses Kafka as API

Interview D:

• Affirms that there might be different communication styles within a system