In this blog we will be going over what is synchronous, asynchronous, what's the difference between the two, and finally an overview of message queues.
Synchronous v Asynchronous Processing:
Synchronous processing is when a caller sends a request for a task and waits for the response before continuing its work. A caller can be a function calling another function, an application or system sending requests to a server. In general, for all of these situations the caller has to wait for the response before continuing.
Meanwhile with asynchronous processing, a caller does not have to wait for a response to come back in order to continue its work.
Lets take for example: the process of making breakfast, we need to make our coffee, eggs and toast. If we were to do this synchronously we would put our coffee to make first and wait until it is done. Once our coffee is ready then we can start on our toast, after we finish making our toast we can now start on making the eggs.
On the other hand if we were to do this process asynchronously, we would put our coffee to make, then we would put our to make, and start on our eggs.
The main difference between these two approaches is that, working asynchronously does not leave you motionless. You don't have to wait for one task to be finished in order for you to continue another.
Message Queues:
Now what is a message queue? Well, in short it is a component that buffers and distributes asynchronous requests. Main responsibility is to be available at all times for message producers and accept their messages. Also focuses on buffering messages and allowing consumers to consume relevant messages. By using message queues we can achieve asynchronous processing when synchronous processing is the default.
Messages:
A message is assumed to be a “one-way” request, a piece of data needed to perform a request. They are created by message producers and buffered by a message queue. After all of this they are sent to message consumers that perform the asynchronous action for the producer.
Message Producer:
Part of the client code that initiates asynchronous processing. Their job consists of creating a valid message and sending it to the message queue. The application developer decides where producers execute and when they should publish messages.
Message Consumer:
Main responsibility is to receive and process messages from the message queue. Are implemented by the application developer, a consumer is a component that does the actual asynchronous request processing. In an application the consumer would pick up the messages from the queue and send them to servers. All consumers do is read messages from the queue and process them.
Producer and consumers usually run as a separate process or execution thread in scalable systems and are usually hosted on different servers . For more flexibility they are often implemented in different technologies. They both work independently and are only coupled by the message format and the message queue location. By having them be separated we get the benefit of nonblocking communication between the two and they can be scaled separately.
The core part of the message queue is the queue itself, it's where the messages are sent and buffered for consumers. A message queue is a component that can have way more responsibilities like: permission control, routing, failure recovery, and is often implemented as an independent application. When having all of these responsibilities it is usually referred to as a message broker or message-oriented middleware. Brokers are just more sophisticated message queues, they are optimized for high concurrency and high throughput. Implementing brokers increases the infrastructure complexity.
____ Thank you for reading!!!
Top comments (0)