Fire and Forget

Courtesy: Amol Sriram Koyya

Long long ago, I attended a training session in Palo Alto, San Francisco Bay Area, USA. Tibco Rendezvous was the topic. That was the first time I came across the word Asynchronous Communication. It didn’t leave me since then!

Communication Patterns

Normally, when two entities are in conversation, the flow goes like this:

1. The first party says something and waits for the second party to respond.
2. The second party processes the information and responds.
3. The first party processes the response and goes back to step-1 if it wants!

In this game, the parties are blocking each other while they are busy processing the information. This is the essence of synchronous communication. In technology, an entity makes a request to the service provider and waits for the response. In other words, the requester is getting blocked while the service provider is taking time to respond.

In a web-scale application, this kind of blocking call hinders the performance.

Let’s look at an alternative:

1. The first party says something and leaves its contact number with the second party to call on when it is ready with a response.
2. The second party notes down the phone number, process the information, and then calls the first party on the saved phone number.
3. The first party receives the callback from the second party, receives and processes the information, and goes back to step-1 if it wants!

Here, the two parties are working independently. None of them are blocking the other. This is referred to as asynchronous communication, a great improvement over synchronous communication.

Technologically, this pattern is implemented in multi-threading, multi-processing, and distributed parallel computing systems.

There is one more flavor of asynchronous communication.

1. The first party says, rather shouts, something without knowing who is the other party.
2. The second party listens to the shouting and processes the information … again without knowing who was the first party.
3. The second party, optionally, shouts with a response in the anticipation that the interested parties are listening to it.
4. The first party listens and receives the response and goes back to step-1 if it wants!

The beauty of this arrangement is that the parties do not know each other. They do not block each other. Communication can be easily one-to-many, many-to-many and etc., In other words, it scales really well. This pattern is called Fire and Forget!

Of course, asynchronous communication has its own drawbacks. It is very difficult to understand, debug, replay the scenarios in an asynchronous system. The transactions that span across calls get even more difficult to handle.

Still, whenever you heard about the patterns like mediator, observer, reactor, Ajax, promises, async-await, event-driven programming, message queues and etc., remember … you are dealing with asynchronous systems.