Asynchronous Communication: Difference between revisions

From NovaOrdis Knowledge Base
Jump to navigation Jump to search
 
(15 intermediate revisions by the same user not shown)
Line 3: Line 3:
* [[System Design#Asynchronous_Communication|System Design]]
* [[System Design#Asynchronous_Communication|System Design]]
* [[Infrastructure_Concepts#Asynchronous_Messaging|Infrastructure Concepts]]
* [[Infrastructure_Concepts#Asynchronous_Messaging|Infrastructure Concepts]]
=Overview=
Asynchronous communication is a communication model used by [[Distributed Systems|distributed systems]] where a sender produces data, also referred to as message, and hands it over to delivery to an intermediate system, not expecting an immediate response to it. The message can reach zero, one or more receivers. Asynchronous communication is fundamentally different from its [[Microservices#Synchronous_Communication|synchronous counterpart]] in that the application thread that sends the message does not block waiting for an answer, but it can move onto performing additional processing.
A response may not be expected at all, and when it is expected, additional logic must be deployed to receive and handle it.
=Benefits of Asynchronous Communication=
* Sending logic is simpler when a response is not expected. The client simply sends the message and moves on. The fact that the API method used to send the message returns without error is a confirmation that the message broker accepted the responsibility of delivering the message. The flip side is that the processing logic is more complex when a response '''is''' expected.
* The sending logic is decoupled from the processing of the message, which usually means that the sender can do other things while the message is being processed. This model is appropriate in case of long running tasks when the message processing takes a long time.
* The communication model addresses well the situation when a message must be processed by multiple components. The sender does not have to connect to all receivers, as it would be the case for synchronous communication, but it does hand over the message to the broker and the broker distributes it to multiple receivers.
=Challenges of Asynchronous Communication=
* More complex error handling. The synchronous communication error model is simpler. In case of asynchronous communication, the sender has to consider situations when the message has been lost in transit, or it reached the recipient and caused an error there, etc.
* More complex logic when a response is expected. The response must be handled as incoming message.
* Reliance on a third party, the message broker.
=Message Broker=
A message broker is an intermediary component in the communication chain that provides the following services: message delivery, message transformation, message aggregation and message routing.
=Message Delivery Guarantees=
* At-least-once: the message gets delivered at least once, but may be delivered multiple times in case of failure.
* Exactly-once: the message broker guarantees that the message will be delivered, and it will be delivered exactly once.
* At-most-once: the message can be delivered 0 or 1 times.
=Communication Patterns=
==Pub/Sub==
==Queues==
=Systems=
=Systems=
* <span id='Kafka'></span>[[Kafka]]
* <span id='Kafka'></span>[[Kafka]]

Latest revision as of 18:45, 5 October 2023

Internal

Overview

Asynchronous communication is a communication model used by distributed systems where a sender produces data, also referred to as message, and hands it over to delivery to an intermediate system, not expecting an immediate response to it. The message can reach zero, one or more receivers. Asynchronous communication is fundamentally different from its synchronous counterpart in that the application thread that sends the message does not block waiting for an answer, but it can move onto performing additional processing.

A response may not be expected at all, and when it is expected, additional logic must be deployed to receive and handle it.

Benefits of Asynchronous Communication

  • Sending logic is simpler when a response is not expected. The client simply sends the message and moves on. The fact that the API method used to send the message returns without error is a confirmation that the message broker accepted the responsibility of delivering the message. The flip side is that the processing logic is more complex when a response is expected.
  • The sending logic is decoupled from the processing of the message, which usually means that the sender can do other things while the message is being processed. This model is appropriate in case of long running tasks when the message processing takes a long time.
  • The communication model addresses well the situation when a message must be processed by multiple components. The sender does not have to connect to all receivers, as it would be the case for synchronous communication, but it does hand over the message to the broker and the broker distributes it to multiple receivers.

Challenges of Asynchronous Communication

  • More complex error handling. The synchronous communication error model is simpler. In case of asynchronous communication, the sender has to consider situations when the message has been lost in transit, or it reached the recipient and caused an error there, etc.
  • More complex logic when a response is expected. The response must be handled as incoming message.
  • Reliance on a third party, the message broker.

Message Broker

A message broker is an intermediary component in the communication chain that provides the following services: message delivery, message transformation, message aggregation and message routing.

Message Delivery Guarantees

  • At-least-once: the message gets delivered at least once, but may be delivered multiple times in case of failure.
  • Exactly-once: the message broker guarantees that the message will be delivered, and it will be delivered exactly once.
  • At-most-once: the message can be delivered 0 or 1 times.

Communication Patterns

Pub/Sub

Queues

Systems