How do microservices collaborate and interact with each other? There are two ways: orchestration and choreography The diagram below illustrates the collaboration of microservices. Choreography is like having a choreographer set all the rules. Then the dancers on stage (the microservices) interact according to them. Service choreography describes this exchange of messages and the rules by which the microservices interact.
Thanks for this great explanation in detail! I think that the orchestration-based communication might possibly make developers stuck in high traffic. Since the choreography-based allows us to make point-to-point communication between the services, we can easily make this communication asynchronous with message queues so that the services can be loosely coupled. Each of them has a single job and if one of them is down, in case of any failure, the rest of them will not be affected (it somewhat affects the transaction but not the whole system). On the other hand, once we apply the orchestration-based communication, there will be a centralized manager that orchestrates the business flow sequentially. In that scenario, what I see is that we somehow need to call the procedures (e.g, REST call) from related services and wait for their responses to execute the next iterations. It might seem like a kind of synchronous centralized communication. Under the high traffic, all related services of a given transaction receive high requests. What do you think about this concern? How do we design our orchestration?
Orchestration and choreography
Do you have any real example about, choreographer and orchestration. When we need orchestration?
as the number of micro-services keeps growing, the orchestrator is going to be a big single service, its maintainability is also a problem?
Orchestrator Scalability vs Choreography??
nicely explained!
Thanks for this great explanation in detail! I think that the orchestration-based communication might possibly make developers stuck in high traffic. Since the choreography-based allows us to make point-to-point communication between the services, we can easily make this communication asynchronous with message queues so that the services can be loosely coupled. Each of them has a single job and if one of them is down, in case of any failure, the rest of them will not be affected (it somewhat affects the transaction but not the whole system). On the other hand, once we apply the orchestration-based communication, there will be a centralized manager that orchestrates the business flow sequentially. In that scenario, what I see is that we somehow need to call the procedures (e.g, REST call) from related services and wait for their responses to execute the next iterations. It might seem like a kind of synchronous centralized communication. Under the high traffic, all related services of a given transaction receive high requests. What do you think about this concern? How do we design our orchestration?