This service consumes messages from the queue one by one and sends emails as specified in the email object. A single consumer microservice, dedicated to sending emails, works completely independently of where the email comes from.Multiple "producer" service which generate emails and require them to be published can push email objects (by objects I mean some formatted objects that contain all nececssary data such as the content, receiver, subject, etc.Delays in the dispatch of these emails is completely acceptable and does not detract from the core functionality of the applications utilizing emails for various purposes. If you think about these use cases, you may realize that none of them need immediate processing. Some of the use cases for messaging queues in real-world scenarios today are listed below: Sending emailsĮmails are used for a large number of purposes, such marketing campaigns, account verification, password resets, et cetera. The processes which are performed by the consumers should, ideally, not be core to the functioning of the overall architecture and functionality of the application, but they may be processes which help improve the functionality and/or performance of the application. Owing to these asynchronous nature, messaging queues are good for processes that are not crucial but nice to have done. But for our understanding, we will be assuming a relatively fail-safe system. That's not exactly true, because in real-world large-scale systems, things like queue overflows may be a real problem. All we have is a guarantee that the message will eventually get consumed and processed. Using messaging queues in a producer-consumer model gives us no guarantee of when the consumer actually will take up the message for processing. To take a made up, unrealistic scenario, using them as an intermediate, say, for an HTTP request where the user has to wait on the response is probably not a good idea. What are some use cases for messaging queues?Īs you might have correctly guessed, messaging queues aren't meant for real-time communication. Let's try to understand a use cases for such messaging queues to aid your understanding. The model is asynchronous in nature, such that the interaction of producers and consumers with the queue is completely independent of one another. As the consumer "consumes" or picks up a message from the queue, the message is removed from the queue. The paradigm is similar to the publisher/subscriber model, whereby multiple publishers or "producers" push messages into "queues", and subscribers or "consumers" can listen for new messages coming into the queue. Messaging queues or brokers are components used for inter-process communication or for inter-microservice communication, whereby messages between multiple services are passed not through direct transfer of data, but through a common "queue" or buffer in the form of these messaging queues. What even is a messaging queue? What is a messaging queue? Let's try to understand that.įirst things first, let's get the absolute basics out of the way. And, perhaps, just like me, you were confused by what messaging queues did and how they helped modern distributed architectures. Perhaps you have heard of companies making use of Apache Kafka, or an alternative like RabbitMQ, those two being the most popular messaging queues in use today. If you have had any amount of interest in things like scalable architectures and microservices, there is a good chance you have come across messaging queues.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |