There are two options when integrating applications:

• Synchronous: Service consumer invokes the service provider and waits for a response.
• Asynchronous: Service consumer invokes the service provider by putting the message on the message broker but does not wait for the response.

The services that we built with Spring Boot in Chapter 5, Building Microservices with Spring Boot, (random service, add service) are examples of synchronous integration. These are typical web services that are exposed over HTTP. The service consumer calls the service and waits for a response. The next call is made only on the completion of the previous service call.

One important disadvantage of this approach is the expectation that the service provider is always available. The service consumer will need to re-execute the service again if the service provider is down or, for some reason, the service fails in execution.

An alternate approach is to use message-based asynchronous communications. Service consumer puts a message on the message broker. The service provider listens on the message broker and as soon as a message is available, it processes it.

An advantage here is that even if the service provider is down for a while, it can process the messages on the message broker whenever it comes back up. The service provider does not need to be available all the time. While there is a possibility of a lag, data would eventually be consistent.

The following figure shows an example of asynchronous message-based communication:

There are two kinds of scenarios where asynchronous communication improves reliability:

• If the service provider is down, then the messages will be queued in the message broker. When service provider is back up, it will process these messages. So, the messages will not be lost even if service provider is down.
• If there is an error in processing the message, the service provider will put the message in an error channel. When the error is analyzed and fixed, the message can be moved from the error channel to the input channel and queued for reprocessing.

The important thing to note is that in both the preceding scenarios, service consumer does not need to worry if the service provider is down or message processing has failed. Service consumer sends a message and forgets about it. The messaging architecture ensures that the message is eventually processed successfully.

Message-based asynchronous communication is typically used in event flows and data flows:

• Event flows: This involve processing logic based on an event. For example, a new customer event or a stock price change event or a currency change event. Downstream applications will be listening on the message broker for events and will react to them.
• Data flows: This involve data that is enhanced through multiple applications and finally stored down to a data store.