3 Message Exchange Patterns in Application Integration You Should Know About (with Examples)

When it comes to application integration, there are various ways to exchange data between them. One that stands out is using their APIs (as long as they are provided) to extract or receive information, either in real time or in batches. Depending on the business needs, different message exchange patterns are applied, and in this article, we would like to list the most common ones, as well as illustrate them with concrete integration examples.

Synchronous vs. Asynchronous Communication

In general, message exchange patterns that enable data exchange between applications are either synchronous or asynchronous, though a combination of these two is also possible.


Synchronous communication is also called blocking communication, because all operations in an application that sends a request are blocked until it receives a reply. The connection between the sender and replier (in the API context, this would be typically HTTP connection) stays open during this period of time. This type of communication is essential when the sender application needs an immediate response to continue with data processing.

Synchronous communication also means that all operations are performed one after the other, or in other words, in sequence. This is why using an integration middleware that ensures very high performance with low latency is key in such integration scenarios — after all, data needs to be processed at very high speed so that no business operations get impeded.


Another name for asynchronous communication is non-blocking communication, because, as you might well have already assumed, the application that sends a request doesn’t have to wait for a reply in order to continue operating. The connection between the sender and replier will be closed as soon as the request has been sent out. This also means that multiple processes can occur in parallel.

This type of communication is especially effective when there are large volumes of data that needs to be processed, and is a better fit when no immediate response is expected or required.

Asynchronous communication is considered to be more reliable than synchronous, as no application would have a timeout because of waiting for responses, which logically leads to higher services availability. Also, additional functionality can be implemented in the messaging system, and not on the communication ends. But really, it completely depends on the use case. There are integration scenarios when asynchronous communication simply won’t work, however fine it is. This needs to be taken into consideration when deciding in favour or against specific message exchange patterns.

Now, let’s have a look at those message exchange patterns, shall we?

Request — Response

This is a very typical message exchange pattern of synchronous communication, and it is what it says: An application sends a request to another application, or if an integration middleware is implemented, to the middleware. It then waits for a response, or a timeout.

Example: In real business situation this would be the case when a support employee needs to call a customer from the interface of the corporate communication tool.

In this scenario, the communication tool doesn’t store customer’s account data, but gets it from a CRM system it is connected to. When the employee clicks on the “Call” button, the communication tool first sends a request for the telephone number to the CRM system, and can perform the “Call” operation only after it receives this number back.

Asynchronous Request-Response

Although the Request-Response pattern is actually considered synchronous by nature, there is its asynchronous variation, which is called Request-Callback.

You are about 51% through with reading the article.

Finish reading the rest 49%