Coordination Patterns
Learn about the two basic approaches used to coordinate different systems.
In many cases, a business function is performed by many different systems that cooperate with each other to perform some part of the overall function. For example, displaying a product page might require combining functionality from different systems, such as an advertising system, a recommendation system, a pricing system, etc.
The previous chapter examined the basic ways in which two different systems can communicate. Now we will explore the two basic approaches that can be used to coordinate different systems to perform a common goal: orchestration and choreography.
Orchestration
In orchestration, a single, central system is responsible for coordinating the execution of the various other systems, thus resembling a star topology, as shown in the following illustration. That central system is referred to as the orchestrator. It needs to know about all the other systems and their capabilities. But these systems can be unaware of each other.
Choreography
In choreography, systems coordinate with each other without the need for an external coordinator. They are essentially placed in a chain, where each system is aware of the previous and the next system in the topology. A request is successively passed through the chain from each system to the next one. We can see this process in the following illustration:
Note: The communication link between two systems can be of any of the two forms described in the previous section. The systems can either communicate synchronously (i.e., using RPC calls) or asynchronously (i.e., via an intermediary message queue).
Each option is subject to different trade-offs, some of which we will discuss in the next chapters.
The behavior of coordination patterns
The patterns mentioned above will behave differently depending on whether the function performed has side-effects or not.
A function with no side-effects
Displaying a product page is most likely a function that does not have side effects. This means that partial failures can be treated simply by retrying any failed requests until they all succeed. Alternatively, if some requests continuously fail, they are abandoned, and the original request is forced to fail.
A function with side-effects
Processing a customer order is most likely an operation with side effects, which might need to be performed atomically. It’s probably undesirable to charge a customer for an order that cannot be processed or send an order to a customer who cannot pay.
Ensuring atomicity
Each of the patterns mentioned above needs to ensure atomicity.
- One way to achieve this would be via a protocol like a two-phase commit.
- An alternative would be to use the concept of saga transactions described previously in the course.
The first approach would fit better in the orchestrator pattern where the orchestrator plays the role of the coordinator of the two-phase commit protocol, while the second approach could be used in both patterns.
Get hands-on with 1400+ tech skills courses.