Espresso Yourself: Computer Communication explained with Coffee

“You cannot not communicate”, the Austrian-American philosopher Paul Watzlawick once said wisely. Communication is complex and comes in all shapes and sizes: Sometimes we wait for an answer, sometimes we do something else until we get a reply. Sometimes we communicate over a third party or with several people at a time. Sometimes we wonder why our counterpart doesn’t answer, or we find ourselves failing to meet the demands of the people trying to contact us. We communicate to buy a coffee on our way to work, we communicate at work and we communicate back at home. We speak, call, present, listen, and we write and read messages. A lot of messages, in fact.

Just as messages are used by people every day to transfer information, the concept of computers exchanging data in a predefined format is called messaging in the field of computer science. Messaging has many aspects, and we’re excited to share the basics with you today.

Asynchronous vs. Synchronous Communication

The primary distinction between asynchronous and synchronous communication is a very simple one. Do you wait for an answer, or do you move on and do something else until you get a reply? In synchronous communication, the sender establishes a connection with the recipient, transmits the message, and then awaits a response. During this time, no additional tasks are undertaken until the communication concludes and the connection is terminated.

This can be compared to the ordering process in a fast food restaurant: When customers order their favorite burger menu, they are not supposed to go to the bathroom after placing their drink order, letting everyone else wait before ordering their meal. The whole ordering process is done in synchronous communication, and customers and workers stop any other tasks and activities until the order placement is completed. Find a diagram of the meal order in synchronous communication below:

With asynchronous communication, the necessity of waiting for a response is eliminated. After the transmission of the message, both the sender and the recipient are free to proceed with other tasks.

In the fast food restaurant example, the way the orders are processed in the kitchen is a good example of asynchronous communication. In this asynchronous process, the order is queued and the worker in the kitchen picks it up as soon as he has at least one thread (or arm) available. Depending on the workload, the worker may process the order immediately or after a few minutes. How exactly the processing of orders is organized might be different from restaurant to restaurant, but the basic elements of asynchronous communication are the same. Find a diagram of the order forwarding from cashier to worker in asynchronous communication below:

Messaging Providers and Queues

While synchronous communication takes place in a direct exchange between two parties, asynchronous communication requires two key components: Queues and the messaging provider. 

The motivation for using queues is that the sender can continue with other tasks. To do this, the message (e.g. order number 5) must be held in the system until it is collected. The solution is a component that temporarily stores messages between sender and receiver. And this component is called... drum roll: Queue!

Like a queue of customers waiting for the cashier to take their order, a messaging queue is an ordered list of messages waiting to be processed.

The concept of queues is especially relevant for point-to-point messaging, where messages from the sender have exactly one message consumer.

In the example of the burger restaurant, the recipients of the message are the employees in the kitchen who take orders from the queue. If someone has to do a shift alone in the kitchen, then that person is the recipient in the point-to-point messaging. This scenario is really stressful, so let's have a quick look at this visualization and then move on...

The entire messaging system, including all queues and the logic for processing the messages, is managed by a special software component. This is where the messaging provider comes in, which is responsible for storing, queuing and forwarding messages. It also ensures that the message is delivered to the recipient only once and in the correct order.

In our fast food restaurant, the messaging provider stores all orders and ensures that each order is processed only once and in the correct order. The cashier could act as the messaging provider here and note the orders on a sheet of paper so that the kitchen staff can collect them. Graphically, this looks something like this:

Publish/Subscribe Pattern

What to do if the messages are to be sent to several recipients? You use the alternative to point-to-point messaging, the so-called publish/subscribe pattern.

In this design pattern, the sender does not send the message directly to the recipient, but links the message to a topic. The recipient subscribes to the topic and receives all messages sent to this topic. This concept is particularly useful if the sender does not know the recipient or if they want to send the message to several recipients.

We promised in the article that it would be about coffee. Now it's time: Imagine the fast food restaurant decides to open a second section, e.g. a café that handles all coffee-related orders. In this case, certain employees in the kitchen are responsible for all orders from the topic "coffee". Other employees continue to process the normal burger orders and do not take care of the coffee orders. In this example, we are in the realm of "Publish/Subscribe" messaging with the topics of “burger” and “coffee”. 

Here, the employees in the kitchen receive messages with orders from their topic. There is also an aspect of order in the queue, as the coffee order placed first should be processed first. However, it is also possible that the burger is ordered after the coffee but is ready before the coffee. This processing time depends on the workload and the current number of employees in the kitchen, be it in the burger or café area.

APIs vs. messaging

APIs (Application Programming Interfaces) and messaging are two different ways to communicate between systems. The differences between these concepts can be described as follows: APIs are synchronous and point-to-point, while messaging is asynchronous and can be point-to-point or publish-subscribe. In other words, APIs are used when the sender needs an immediate response from the recipient. Messaging is used when the sender doesn’t need an immediate response or when the recipient is not available at the time of sending the message. The amount of recipients can vary when using messaging.

In the example of the burger restaurant, the API could be the beverage vending machine in the restaurant, where the customer can order a drink and immediately receive it. The messaging system would be implemented in the self-service terminal, which stores your order until the worker in the kitchen picks it up.

Ok cool. And now?

Please bring your seat into an upright position, we’re landing this plane with another inspirational quote: “Communication works for those who work at it” (John Powell). The fact that you read this article to the end proves that you’re willing to work on the communication of your application. You learned that there are many different concepts to implement communication between components and none of them is universally superior. The choice between asynchronous or synchronous, point-to-point or publish-subscribe messaging depends upon the specific use case at hand. In the end, the highest objective remains to ensure that the burger (or whatever service you are selling) is delivered to the customer in time.