Define Interservice Communication

Orchestrator

Synchronous architecture where the workflow is managed by the orchestrator service

Pros

Central observability of process definition, status, and metrics

Cons

Single point of failure
It tight couples the orchestrator and other services
It has some domain knowledge about the responsibilities of the services. Adding/removing services means modification of the code

Choreography

Asynchronous architecture where the workflow is operated by each service pushing and subscribing to message broker queues/topics

When To Use

When You need to tackle orchestrator bottlenecks. Also when you remove, or add new services frequently

This pattern is a natural model for the serverless architecture where all services can be short lived, or event driven. Services can spin up because of an event, do their task, and are removed when the task is finished.

Pros

Service decoupling
Removes orchestrator bottleneck

Cons

Difficult to trace it (distributed tracing)
If a service fails to complete a business operation, it can be difficult to recover from that failure
The workflow can become complicated when choreography needs to occur in a sequence

Service-to-Service

Mostly synchronous communication between services.

In general it is considered a bad practice and should be avoided as much as possible. Of course this is not applicable as a service might needs to communicate directly to another one. The type of communication is separated in the following categories:

Query: service A needs some info from the service B, such as "Hey, give me the buyer information for a given customer Id."
Command: service A needs service B to execute an action on behalf. For example "Hey, just ship this order."

Useful links

Detailed explanation about interservice communication here

Crafting-Playground / Prototype