Synchronous communication happens in real-time - like making a phone call and waiting for the person on the other end to answer what you say. Asynchronous communication, on the other hand, doesn’t require any waiting for responses in real-time. The advantage is a higher ability to multi-task since there is no waiting for one task to finish before starting another. A good example of asynchronous communication is email - once an email is sent, other tasks can be performed without requiring an immediate response. While the response is in transit, other tasks can be completed.
Asynchronous communication enables flexibility to send a message out and keep working on other things; synchronized communication requires waiting for a response before moving on to other tasks.
Asynchronous communication in computer systems
If one system goes down in a system of asynchronous applications, the other system will not be impacted. The task will be on hold until the other system is up and running again. Web applications that receive a lot of requests are able to generate tasks in response to user input and send them to a receiver. The receiver retrieves the task and processes it when the receiver is ready, returning a response when it is finished. This way the user interface remains responsive all the time.
How to implement asynchronous messaging in the cloud?
Asynchronous messaging in the cloud is usually implemented using message queues, a message broker. The basic architecture of a message queue is simple - there are client applications called producers that create messages and deliver them to the message queue. Another application, called the consumer, connects to the queue and gets the messages to be processed. Messages placed onto the queue are stored until the consumer retrieves them - it does not even have to be running concurrently. When a message is retrieved, it is processed by the receiver and then removed from the queue. Building an application in this architecture decouples the sender from the receiver, meaning that the sender and receiver of the message do not need to interact with the message queue at the same time.
RabbitMQ as a message broker
An example of a message broker is RabbitMQ. A message broker usually provides features around the task messaging, such as these features available in RabbitMQ:
Message routing
When sending a message to a queue involves sending the message to an exchange instead of straight to a queue. RabbitMQ exchanges are similar to telephone exchanges, but instead of routing phone calls, it routes messages. A telephone exchange helps route the phone call to the correct receiver with the help of a given phone number. In RabbitMQ, and exchange helps route the message to the correct queue with the help of attributes located in the message that.
Different types of exchanges are used to reach different goals and different routing logic. The message can be sent out to a single queue (a single address), or to many queues that broadcast the message to multiple consumers.
Messages can be exchanged in a format according to user preference (e.g. JSON, binary, etc.). One great approach with this kind of setup is the ability to broadcast events – your service does not really have know its audience. For example, the exchange could send the message "User update". The services that are interested in such information subscribe to these messages and process them one by one.
RabbitMQ provides four different types of exchanges.
Acknowledgement
RabbitMQ supports message acknowledgments to make sure that a message is never lost. An acknowledgment is like saying 'thank you' after you have received something. Acknowledgment is sent back from the receiver to tell the message broker that a particular message has been received and that the message queue is free to delete the message. If a receiver dies without sending an acknowledgment, the message queue will understand that the message wasn't processed fully and it will redeliver the message to the queue so that no message is lost.
Persistence, clustering and highly available queues
Message queues and messages can be persistent, which means that information will not be lost in case of a restart. A message queue in RabbitMQ provides messages a safe place to live until they are received. Several RabbitMQ servers can be clustered together to form a single message broker. Queues can be mirrored across several machines in a cluster, ensuring that even in the event of hardware failure the messages are safe.
Management UI, tracing and plugins
RabbitMQ Management is a user-friendly interface that allows for monitoring and handling tasks in the RabbitMQ server. Among other things queues, connections, exchanges, users and user permissions can be handled (created, deleted and listed) through the browser. Message rates can also be monitored as well as sending and receiving messages manually.
RabbitMQ offers trace support, which helps users get more information if the system is misbehaving.
Basic RabbitMQ systems are greatly enhanced through the use of plugins offering all kinds of useful features for many users. Today, RabbitMQ arrives with a wide variety of plugins to meet the needs of almost every use case.
Getting started
RabbitMQ includes a wide variety of features that make it useful when building distributed systems that communicate via asynchronous messaging. To get started, reading our RabbitMQ - Getting started guide is a great way to learn more about message queue architecture!
Please email us at contact@cloudamqp.com if you have any suggestions, questions or feedback.
