Asynchronous Messaging

No alt text provided for this image

Visit systemdesign.us for System Design Interview Questions tagged by companies and their Solutions. Follow us on YouTube, LinkedIn, Twitter, Medium, Quora.

What is Asynchronous Messaging? – Basic Definition?

Asynchronous by definition means two or more things that do not happen at the exact same time. In case of distributed systems, it means two systems that communicate with each other do not generally wait and stop their processing to receive a message from the other. These systems process messages at their own time and pace, and the system that originated the message does not wait for the receipt either, which allows them to execute other things than just waiting around wasting processor time while the messages are transferred between them most probably over a distributed network.

In more simple terms, systems that communicate asynchronously, work something like this client-server example. A client makes a request to the server by sending it a message. If the service needs to send a reply to that request, a different and new message is generated and sent back by the server to the client. It is also understood by the client that it won’t receive the response from the server immediately or maybe ever. And it needs to anticipate and be prepared for all such possibilities.

??

Where is Asynchronous Messaging used? – Real World Use Cases

Any sufficiently complex and distributed system does eventually resort to using some version of asynchronous messaging for a variety of reasons discussed in this article. Here are some real world examples where it is used.

Netflix – Given the scale of Netflix usage they decided to use Kafka for streaming and their analytics events pipeline. Netflix Blog

Paypal – A critical infrastructure platform like Paypal also uses Kafka for maintaining their payment infrastructure. Link

??

Why did Asynchronous Messaging even become popular? – Macro Trends

As software systems on the internet have become more complex with the proliferation of the internet, it has become hard to develop and maintain them. This gave rise to microservices architectural style of writing software. This style allows smaller services to be developed, operated, scaled up and updated individually, without relying on other services. However, these services still need to communicate amongst them in a reliable manner but this communication cannot be tightly coupled.

One of the ways to communicate between two loosely coupled services it to use REST APIs. They offer one way to loosely couple smaller systems, where implementation is hidden behind interfaces. However there are a couple of problems with them. One being in most cases, REST APIs require responses by the other system. This adds synchronicity to the smaller services. Another one is the added overhead of maintaining REST interfaces and their implementation.

Given all of the trade offs above, asynchronous messaging starts to make sense for integrating independent smaller systems, so that they can develop and scale flexibly. They allow messages to be persistently stored, thus also maintaining reliability.

?

How does Asynchronous Messaging work? – Design & Architecture

All asynchronous messaging systems like Kafka have at least three important capabilities.

1.???Become a producer or a consumer of messages

2.???Provide persistent storage for messages

3.???Process messages as they are received or in retrospect

These messaging systems are distributed systems themselves, with each containing a cluster of servers. These servers are responsible for importing and exporting data as well as managing the storage for this data. They also contain various implementations of clients that can be used to integrate and use these messaging systems in your distributed system.

Given this basic structure, individual implementations differ in a variety of ways that give them special characteristics. These differences make them optimal for different types of problems. The best way to decide which implementation is best for you depends entirely on which parameters of the system you are optimizing for. So please go through various options that are available to you to decide the trade offs at your disposal.

Here is a very general architecture of a messaging system. The strategy of creating partitions and sub partitions, how their data is stored per partition determines the types of problems that particular system is optimized for. For example in some cases, the data storage is consistent and distributed, where as in other cases it can be distributed but stored separately per partition without consistency. This fundamental assumptions will determine if you can use that system for your case.

?

Here are examples of a couple of systems.

Kafka - https://kafka.apache.org/documentation/

RabbitMQ - https://www.rabbitmq.com/documentation.html

https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/asynchronous-message-based-communication

https://betterprogramming.pub/rabbitmq-vs-kafka-1ef22a041793

?

What are the benefits of Asynchronous Messaging? - Advantages

Here are some of the benefits to be had when using asynchronous systems.

Reliability – Distributed systems are loosely coupled compared to monolithic systems. This increases the chances of data loss during communication. Asynchronous messaging systems persist data which makes the system more fault tolerant.

Performance – Overall efficiency of the system goes up, as the individual sub-systems do not have to wait for each other to complete other tasks. They can interact with queues which keep track of communication points between different components.

Decoupling – Features offered by messaging systems allow smaller sub-systems of a large distributed system to be independent and simple. The communication overhead in terms of software development and its executions is reduced and delegated to the messaging system. This allows these sub-systems to focus on business logic.

Scalability – Decoupling of smaller sub-systems also allows them to be scaled individually and flexibly. This allows for more precise control over how many resources you want to deploy, where do you want to deploy them and at what time.

?

What are the downsides of Asynchronous Messaging? – Disadvantages

As we very well know, there is no silver bullet. Here are some of the downsides of using asynchronous messaging systems.

Single POF – Messaging systems introduce a single point of failure in a distributed system. This problem is somewhat mitigated by the fact that these are distributed themselves. But a software bug or a bad design could still bring entire clusters down.

Data Inconsistency – Distributed nature of communication by definition introduces latency in communication as it happens over a network and not inside a single computer. Therefore, it requires extra effort to maintain consistency of data within the whole system if such a thing is needed.

More Work – Messaging systems have their own set of issues with maintenance. For example in case large throughputs, backlogs get formed in them and it becomes harder to debug these issues in a live system. It is harder to change the design of your queues once it is deployed into production and they also require careful consideration around data migration and switch over to the new design. New usage metrics also need to be tracked, in addition to your other sub-systems.

??

How should you decide if you need to use Asynchronous Messaging? – Do I need this?

Whether you should use a particular tool, is the question you’ll encounter over and over again while building distributed systems. Unfortunately only the people working on the actual system have the required context around business cases, hardware infrastructure, tools that are already being used in the team, their technical expertise and of course budget. Without considering all of these, it is almost impossible to make an informed decision that works in every case for someone who is not actively solving that problem. However, here are some guidelines in terms of technical considerations to help you make your decision.?

Complexity – If your distributed system is getting more and more complex over time and rate of failure in communication has been going up, this might be a good time to introduce a messaging system into the mix. This will reduce your code complexity from individual components.

Data Loss – If you are increasingly observing some of the requests failing or taking a long time to get a response from the other parts of the system, messaging system might help in providing persistent mechanism to store those messages until another sub-system has gotten a chance to act upon it.

Scaling – When you try to scale parts of your distributed system, but you realize that they are tightly coupled in a way where you cannot scale up or down one of them without affecting the other easily, messaging system may provide a way to achieve individual and flexible scaling strategy. As the traffic or usage of your system increases, messaging system might be your choice to move between scaling various components of the system up or down independently.

??

Where can I get even deeper understanding of Asynchronous Messaging? – Mastery

https://dl.acm.org/doi/abs/10.1145/1028509.1028513

https://books.google.com/books?hl=en&lr=&id=bUlsAQAAQBAJ&oi=fnd&pg=PR7&dq=+what+are+asynchronous+messaging+systems&ots=58XwW6IXO8&sig=iMchAao3rQ-mKKszKDoPAbCEhaE#v=onepage&q=what%20are%20asynchronous%20messaging%20systems&f=false

https://ieeexplore.ieee.org/abstract/document/882535/references#references

https://pages.cs.wisc.edu/~akella/CS744/F17/838-CloudPapers/Kafka.pdf


Visit systemdesign.us for System Design Interview Questions tagged by companies and their Solutions. Follow us on YouTube, LinkedIn, Twitter, Medium, Quora.

要查看或添加评论,请登录

System Design的更多文章

社区洞察

其他会员也浏览了