Microservices can communicate in a synchronous and asynchronous manner. However, as things evolve, there is an insistence for event-driven microservices, which, in turn, ask for asynchronous interactions. In this section, we are going to discuss some of its motivations. 

 We have been fiddling with synchronous communications. We are more comfortable with TCP, HTTP, and FTP protocols, which intrinsically support synchronous communication, which has certain advantages. The overwhelmingly used interaction model of request and response is being accomplished through synchronous communication pattern. However, the world tends toward an asynchronous communication pattern. If the server application is heavily loaded, then clients have to wait to get the response from the server. How can this situation be handled? That is, how can a long-running business process on the server machine can be elegantly communicated to the client? If a server-side service is not available due to one of the typical reasons, then how can the client handle this scenario? As there are redundant service instances, how can the client be empowered to take a different route to the functioning service to handle the client request? How can a guaranteed server or service response time can be ensured to the client is another huge challenge in this extremely connected world? There are other challenges, too.

The asynchronous communication is expected to relieve us from these pains. Long running tasks, unavailable or unresponsive servers, service transparency, request reordering and prioritizing, and so on, can be easily accomplished through asynchronous communication. Now, let's discuss the nitty-gritty of the EDA pattern.

An EDA consists of event producers that generate a stream of events, and event consumers that listen for the events. Events are delivered in near real-time, so consumers can respond immediately to events as they occur. Producers are decoupled from consumers. An EDA can use a pub/sub model or an event stream model. Refer to the following points:

• Publish/subscribe: We have detailed this further on. Due to the production of a staggering amount of events, competent messaging middleware solutions abound to precisely keep track of event subscriptions. That is, when a tangible event gets published, the messaging infrastructure sends the event to each of its subscribers. Once an event is received, it cannot be replayed again. Furthermore, new subscribers can't see the event.
• Event streaming: Events are streamed and written to a log in an orderly manner. Events are persisted to be durable. Clients don't subscribe to the event stream. Instead, a client can read any part of the stream. A client can join at any time and replay events.

Events may be simple or complex. Lately, there has been a number of streaming analytics platforms and event processing engines being made to make sense out of event streams. These days, the application design is increasingly event-centric. Events have acquired such a dominant position in the business and IT worlds. Data-centricity is steadily tending toward event-centricity. The enterprise and cloud IT teams are tasked with having event platforms in place to succulently extricate beneficial associations and patterns, fresh possibilities and opportunities, outliers/anomalies, risks and rewards, and so on. Refer to the following points: 

• Simple event processing: An event immediately triggers an action in the consumer.
• Complex event processing: Complex events are typically a series of events and a consumer is supposed to process complex events searching for actionable insights in the event data.
• Event stream processing: It is all about using an event-streaming platform, such as Apache Kafka, as a pipeline to ingest events and feed them to one or more stream processors. The stream processors process or transform the stream accordingly.