Asynchronous Communication: 5 Main Points

A few weeks back I read the famous book “Synchronicity: The Art of Coincidence, Choice, and Unlocking Your Mind” by Dr. Kirby Surprise. It was an amazing book but it brought an interesting contract to my mind. In real life, synchronicity is underplayed and mostly not understood well. In software architecture interestingly same can be said about asynchronicity.

Asynchronous communication is such a core architecture principle that it should be regarded as a virtue. It is so important that software architecture created without the consideration for asynchronous communication is definitely a bad architecture. In other words, asynchronous messaging is the necessary but not sufficient condition for a sound architecture. In this blog, we are going to cover different ways this principle manifests itself.

Now, let’s dive in.

The Hollywood Principle or Inversion of Control (IoC):

Allegedly the origin of the famous Hollywood principle in software design is based on the belief that when an aspiring actor finishes an audition, he/she is told “Do not call us, We’ll call you”. In software terms, it means we separate the creation and binding of an object. This pattern is commonly known as Inversion of control and is achieved via dependency injection.

An example can be how database instances are injected in the ephemeral environments Roost creates. Since environments are stateless, they have no idea what type of test data it will get until the runtime binding happens. Dynamically (as opposed to static testing) Roost figures out the relevant dataset from the production data, anonymize it as needed, and injects it into the running environment on the fly.

The Air Traffic Controler or Mediator Pattern:

The most traditional example of breaking dependencies is by using a message bus. This is not the most effective design in the cloud-native world but it’s very convenient as every company has some form of message bus already implemented.

Messaging architecture based on Apache Kafka is a good modern example of this pattern. A good traditional example is Tibco Message Bus (Rv, JMS, etc) which enabled high-frequency trading.

Messaging is Dead, Long Live Eventing:

The traditional design around messaging is so arcane that new-age developers coined a new term i.e. “eventing”. The key idea is that:

1. the internal state of a software component is its internal business and the external world should not care about it.
2. while the old messaging architecture meant the creation of a specific messaging, in eventing no message is created. Life-cycle events of a component or service are simply exposed on standard output and error channels and whoever cares should simply observe these events (therefore observability)

As an example, Roost’s asynchronous messaging architecture is actually an eventing architecture as no messages are ever sent. Any other service which is interested in the life-cycle of a target service or container should simply watch out for life-cycle event signals in addition to golden signals.

Live n synchronous virtuous life.

When we designed the initial architecture of the Roost “Environments as a Service platform”, the very first component we built was asynchronous communication based on 4 golden signals i.e. latency, traffic, error, and saturation. It was not something we even had to debate about as we all in the founding team knew that all great software is built on a good messaging backbone.

This post was created with Typeshare