This is going to make the system more scalable.Īnother big benefit of message queues is that the queue itself can sit on its own machine/server. In our case, more than one consumer (System 2) to read from the queue to handle the amount of workload that the checkout is producing.

Similarly, the consumer (System 2), when it's ready, can consume from the queue, process the message, then immediately consume the next message this is going to decouple the two applications.Ī message broker also helps with the scalability if a lot of checkouts happen at once, the queue begins to fill, which means we can have more consuming service. Message Queues sits in between the two services that need to communicate with one another, as shown in the below diagram:Ī producer (System 1) can add a message to the queue and immediately move on to the next task. So, that's why message queues/brokers were created. If a lot of checkouts happened at once, the inventory service wouldn't be able to keep up and the whole system would get stuck.If the inventory service went down, it would try over and over again until it was able to make that connection.As soon as checkout sends the message, it would need to hear a reply before it could move on to the next task.In the days of monolithic architecture, application components were tightly coupled, which means they were directly connected.Ĭonsider a simple eCommerce application we have a payment service, and it needs to communicate with a payment gateway service, which would be done directly through a TCP connection.

Message queue broker