Have you’ve ever visited India? How did you cope with the traffic there? It’s clearly different to the regular, organized approach we are used to in Europe.

After spending a couple of days in Bangalore recently, I became aware that my reaction to traffic had changed; I was not fazed (read terrified) by traffic behavior anymore and actually started to notice how well it seemed to work. This surprised me and got me thinking: “is this an example of choreography and if so, is driving in Europe orchestration?” Let me explain.

In Europe (as in most of the world), traffic is managed by lanes, signs and traffic lights. Obeying these is paramount and heavy fines are imposed on those who flout the law. Everything seems to flow in unison and order seems to be present. But is it? What happens if we don’t respond to instructions in time, or don’t follow proper lane etiquette? Traffic blockages and potentially; road rage.

Counter that with the scenario in India; everyone seems to react to changes by other drivers, lanes seem to be indicators of general direction and traffic signals are only placed on major intersections (sometimes enforced by a traffic official). This apparent chaos often scares those of us not form the region, but yet it still seems to work.

APIs, by nature and design, decouple us from the complexity of the underlying systems. Inversely, when we expose our data via APIs we cannot expose our complexity (like we may have done in the past). So, with APIs, the general practice seems to follow our driving behavior; we want to control what and who we share our data with. We want to be the masters of orchestration to maintain control. We want to feel like we are still empowered.

Choreography is a completely different approach, here we are no longer the master of what happens to our data or who uses it. As I mentioned in my article on the Hollywood Principle; we expose our data as events when our work is done. Essentially, we’re sharing the result of that piece of work with the world – “I’ve done something you may want to know about”. How and what the consumers do with the data should be of no consequence to me, but it feels like I’ve lost control. Consumers (or subscribers) react to my data changes – each choreographing their own behavior. It’s synonymous with driving in India.

Now, I am by no means saying we should abandon all structure and formality and start driving like we are in India – that was merely a metaphor to explain choreography. Perceived chaos seems to work in India but would not necessarily work in Europe. An event-driven architecture, which induces choreography, has its place, but then so does orchestration – it depends on the agenda, use, and purpose of the integration. I find the problem is that people appear to be afraid of choreography because they cannot control it, and therefore dismiss a reactive event-driven architecture and the opportunities that go with it.

In summary, Orchestration is the process where a single API consumer gathers information from various API endpoints, using the data received from initial calls to make further API calls to other endpoints. Choreography is the process where multiple subscribers react to a single event, using the data received for their own purposes.

I introduced the concept of a layered API architecture in a previous article where I mentioned the creation of core domain API. These core domain API, being data-based, are in my mind the best data components for sharing in an event-driven architecture – since they describe a single entity within a single domain – allowing maximum coverage by multiple subscribers.

Finally, what about composition - another strategy used with APIs which I have not mentioned? Using the traffic metaphor; composition is similar to putting the passengers into the car – a collection of objects (people) defined as one (car). Composition is the process where a single API consumer gathers data from multiple endpoints. However, unlike Orchestration, Composition does not require one or more previous API calls to provide data for subsequent calls.

Craig Hughes

Image sourced from medium.com