Link to Video

In this video, he again comes back to the pizza shop example and explains message queue.

In a pizza shop when orders keep coming in or multiple orders keep coming, you can keep adding the orders to a list or "queue". Then after you have prepared the pizza, remove the order from the queue and ask for payment from the customer. So, what this did is, allowed the client to do other things while their pizza was being made like they can check their phone, go for a walk etc. This also allows us (the pizza maker) to prioritize tasks. Basically, we are doing asynchronous processing.

Why we need message queue ?

Suppose you have mutiple pizza parlours and orders are coming in to each of them. Each of them also have a list(or a queue) which stores the order numbers, this list is store in-memory. Now, if there is a power outage in one of the stores, we would want to route(something like load balancing) our orders to a different store, but since everything was in-memory we will lose our data and not be able to route. So, we need persistence. Persistence can be achieved with databases.

Here is a diagram below (taken from his videos) that is used to explain the concept of message queues further.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/8f4235b0-5a4f-42bb-a83b-027d25d496e7/A47A3C59-61B3-411D-B567-65AC96664DAC_4_5005_c.jpeg

Assume there are 4 pizza servers S0, S1, S2, S3 and server S3 faces a power outage. Assume order number 9 is coming to S3 and we need to route it to some other server.

Firstly, we need to know when to route the orders(analogous to requests). We could have a notifier mechanism which gets alerted when a server goes down and then it re-routes the requests. But what would be more efficient is that the notifier periodically polls the servers to check if they are running. If a server does not respond to the notifier, the notifier reroutes that servers requests.

<aside> 💡 This mechanism of the notifier periodically pinging multiple servers is called heartbeat mechanism.

</aside>

Now we come to the part where we decide how the notifier re-routes the requests. One way of doing this is , the notifier queries the database which orders are of server 3 and then redistributes it. But this may cause issues like distributing same orders to multiple servers. So we use the concept of load balancing and consistent hashing for distributing the requests.

<aside> 💡 We can conclude that we need heartbeat mechanism, load balancing and persistence all in one for the task above. These three are provided by message queues. RabbitMQ is a popular message queue service.

</aside>