Integration Strategies for Microservices: Choreography and Orchestration
What starlings can teach us about decentralized workflows — exploring how choreography and orchestration shape communication and coordination in microservice architectures.
Starlings are birds originally native to Europe. In the 19th century, a businessman named Eugene Schieffelin introduced them to North America. According to an urban legend, his motivation was to bring this species to America so that every bird mentioned in Shakespeare’s works would be present there.
Although this story is widely disputed, starlings are a magnificent and interesting species of birds. What makes them particularly fascinating is their collective behavior in flocks. Starling flocks contain up to thousands of birds and provide mesmerizing, coordinated flight patterns (called murmurations) - all while individual birds follow simple rules like maintaining distance, aligning with neighbors, and steering towards the flock’s center.
What is so intriguing about these phenomena is that they work without central control, relying instead on communication between individual birds. To bring these ideas back to software systems, today I want to discuss a concept called choreography.
Choreography
Imagine your starling birds now as microservices. Choreography is a communication strategy that integrates parts without requiring central control. Individual services execute a workflow by transmitting information to each other in a decentralized manner. This is done by emitting events, which are notifications of something that happened, without knowing who will handle them. I have written about events in “Event-Driven Communication and Its Effects on Team Independence”:
Events are statements of facts that occurred. The emitting module releases an event, letting others know something happened, like "new order placed" or "order canceled". They never induce a direct reply because replying to statements of facts would not make much sense. Events have an effect that commands or queries do not. The producer has no knowledge of the receiving modules, their behavior, or what they do with the data. It releases the event and considers its job done, reducing the coupling between modules. Events are often used in combination with the publish-subscribe pattern. […] Usually, any module interested in a specific type of event can subscribe to it.
What happens in choreographed workflows is that the overall workflow emerges as a pattern of independent reactions between services, rather than being explicitly defined in a single place. Because each service's activation logic is embedded locally, the overall workflow behavior becomes distributed across services.
While this emergent behavior seen in choreographed systems and starling flocks benefits the autonomy of individual services, the lack of explicit workflow logic representation in a single location can sometimes cause issues, such as errors that are hard to trace. This is why an alternative approach to choreography exists, which is known as orchestration.
Orchestration
Placing workflow logic within a single microservice, which then controls the invocation of other services, is known as orchestration, and the central microservice is correspondingly called an orchestrator.
While the invoked services have no knowledge about the orchestrator, the other way around is (obviously) the case. In this way, orchestrators are able to centralize workflows and complex invocation logic - with all the trade-offs this creates.
Conclusion
Clearly, neither choreography nor orchestration is inherently and objectively superior. As I personally lean towards choreography, especially when the communication crosses teams and bounded contexts, I acknowledge that orchestration provides value in depicting workflows which require some tasks to be executed in a certain order. However, I always try to build my module boundaries around these consistency/order requirements such that I use orchestration more often within those bounded contexts. This way, the communication overhead that comes with extending orchestrated systems does not cross team boundaries and the knowledge of the process coordination remains local and within the same team.