In this video, explore asynchronous communications and how they apply to microservices architectures.
- [Instructor] When dealing with system to system calls, there are only two strategies. The traditional model that most of us have dealt with is the synchronous model. The asynchronous model of interservice communication, however, has significant value. Before we talk about asynchronous communications in microservices, I want to spend a moment and talk about standard microservices communications. In a standard model, service to service communications is over HTTP using RESTful patterns. The calls are synchronous in nature, meaning that the caller waits for a response, but more importantly, that response is sent after the request is fully processed. Each call, therefore, becomes a blocking call that the client must wait on a success or failure indicated by status codes from the service being called. As such, in this model, call paths can become deep. Now, it isn't usually a big deal in small, concise operations, but it can become a bottleneck for longer processes across many services. As a contrast, the other option and the focus of this course is asynchronous communications. There are a couple of ways to implement asynchronous communications, and the first is over HTTP using REST. In this model, the client sends a call and the server immediately responds with an accepted status code. The client then either pulls the server or waits for a push message on a callback URL to determine if the work was done and successful or done and failed. Another method, and the ultimate focus of this course, is through the use of messaging systems like Rabbit, Kafka, JMS, or others. We will discuss many different ways of implementing messaging patterns throughout this course, but for now we will simply say a message is put on a system and a downstream consumer works on that message. many different ways, or not at all, in these various patterns we will discuss. Now, if you were thinking to yourself that can be more complex, you're right. In fact, it can be very difficult to do them right, but there are benefits. One of the biggest benefits is offloading strain on the system. By not having every call be a blocking call, you can leverage more processing power behind the scenes and not impact your customer. And after all, not every call needs an immediate response, and since there's a correlation between user wait times and satisfaction, the offloading to asynchronous can improve satisfaction of users, and in an e-commerce system, for instance, that can translate to money. In addition, many jobs take a while to run to completion, and using asynchronous communications not only offloads strain, but in doing so, keeps the system as a whole healthier. Asynchronous communications, especially in workloads and DAG, or directed acyclical graph workflows, can allow you to build in natural retries without negatively impacting performance Now, this is just a very brief introduction to the needs for asynchronous communications in a microservices system, and as we move throughout this course, you will see concrete use cases where this communication style and the associated patterns can greatly improve your system viability, scalability, and overall operations, which is why we build microservices in the first place.
- Gains and tradeoffs of asynchronous communications
- Use cases for interservice communication patterns
- Event-driven microservices
- Use cases for choreographed and orchestrated events
- Streaming data platforms
- Data flows, migration, and synchronization