6 Comments

Do you have any real example about, choreographer and orchestration. When we need orchestration?

Expand full comment

as the number of micro-services keeps growing, the orchestrator is going to be a big single service, its maintainability is also a problem?

Expand full comment

Orchestrator Scalability vs Choreography??

Expand full comment

nicely explained!

Expand full comment

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?

Expand full comment