The labs on this site need JavaScript to run. The same content is written out below.

Fundamentals › Architecture and operations

Message queues

What is a message queue, and how is it different from calling a server directly?

A message queue is a line, placed between the server that asks for work and the server that does the work, in which the work is written down. The code box has three lines. In the first line, the order server writes the work for the notification server as a short text (a message) called "Notify order N" and puts it in the queue, and when it gets the result it moves straight on to the next job (the side that sends messages). In the second line, the queue keeps the messages in the order they were put in. In the third line, the notification server takes messages out of the queue one at a time and handles them (the side that receives messages). In this lab you remove the queue line so that the order server sends requests straight to the notification server, or you keep the notification server stopped while the 3 orders are sent and start it later, and you see the result the order server gets and how the notifications are handled. The code box is not the source of a program that was run. It is text that says what does what, and the queue used in the runs is a very small queue server written for this lab (it is not a real product such as Kafka or RabbitMQ).

Checked against real execution · Ran four combinations with two Node.js 24.18.0 http servers (a small queue server written for this lab and a notification server that receives direct requests) and a program that plays the order server, and checked against the model. Real products such as Kafka and RabbitMQ were not run

Concepts in this lab

Message queue

An intermediate store that sits between the sending side (the producer) and the receiving side (the consumer), holds messages, and then delivers them. The producer puts a message in and moves straight on to its next work, and the consumer takes messages out and processes them at its own pace. The two systems do not call each other directly, so coupling is lower, and a sudden burst of requests can be piled up and processed later.

Producers and consumers

A producer is a program that creates and sends messages, and a consumer is a program that receives those messages and handles them. The RabbitMQ tutorial calls a program that sends messages a producer and a program that mostly waits to receive messages a consumer, and the Kafka documentation calls a client application that writes events a producer and the side that reads and processes events a consumer. When a queue sits between them, the producer only puts messages in the queue, and the consumer takes them out of the queue when it is ready. The Kafka documentation explains that the two are fully decoupled and agnostic of each other.

Message broker

A message broker is an intermediate program that receives the messages a producer sends and passes them on to a consumer. The RabbitMQ tutorial introduces RabbitMQ as a message broker that accepts and forwards messages. Inside a broker there are queues that keep messages, and the same tutorial describes a queue as a large message buffer that is bound only by the memory and disk limits of the host. Producers and consumers do not connect to each other directly. They exchange messages through the broker.

Try these

• Default settings — The order server puts messages in the queue and gets the result at once. After that, the notification server takes them out and handles them in the order they were put in.
• Calling directly without a queue — The order server waits until the notification server has finished handling the request, and only then gets the result.
• Calling directly while the notification server is stopped — All 3 requests fail, and even after the notification server starts there is no notification to handle.
• Using the queue while the notification server is stopped — The 3 orders succeed, and the messages stay in the queue and are handled after the notification server starts.

Running with the default settings

1. The order server receives the 3 orders one after another. As the first line of the code box says, each time the order server receives an order, it writes the work for the notification server as a short text, "Notify order N", and puts it in the queue. This short text is called a message. The queue is a line that keeps messages in the order they were put in, and the notification server takes messages out of the queue and handles them. The notification server is running now, and the queue was empty when it started. The notification server looks into the queue every 0.1s and takes out a message if there is one. In this run, handling one notification was made to take 0.3s.
2. The order server sends a request to put the message "Notify order 1" in the queue. The queue keeps the message at the tail and replies "put." The moment the order server gets this reply, it gets the result of this order (success) and moves on to the next order. This reply does not say whether the notification server has handled the message. The number of messages piled up in the queue is 1.
3. The order server puts the message "Notify order 2" in the queue, and as soon as the queue replies "put," it gets the result (success). The number of messages piled up in the queue is 2.
4. The order server puts the message "Notify order 3" in the queue, and as soon as the queue replies "put," it gets the result (success). The number of messages piled up in the queue is 3.
5. The order server has got the results of all 3 orders. The notification server is running, but it looks into the queue every 0.1s, and handling one notification takes 0.3s. So when the order server has got all the results, not one notification has been handled yet, and 3 messages are waiting for their turn in the queue. The order server cannot know when these notifications will finish.
6. The notification server takes the message at the head of the queue, "Notify order 1," and handles it (0.3s). 2 are left in the queue. Messages are taken out in the order they were put in.
7. The notification server takes the next message from the queue, "Notify order 2," and handles it. 1 are left in the queue.
8. The notification server takes the next message from the queue, "Notify order 3," and handles it. 0 are left in the queue. All 3 notifications have been handled. The order in which they were handled is orders 1, 2, and 3, the same as the order they were put in.

Result of this run

• A message queue is a line, placed between the order server and the notification server, in which work is written down. The order server only put messages in the queue and got the result at once, and the notification server took them out of the queue in the order they were put in, at its own speed, and handled them.
• In exchange, when the order server got the results, not one notification had been handled yet. Success only means that the message was put in the queue, so the order server cannot know right away when the notification will finish.

Code

# Order server: for each of the 3 orders, puts a "Notify order N" message in the queue
# Queue: keeps the messages in the order they were put in
# Notification server: takes them out of the queue one at a time and handles them

Assumptions of this model

I ran all four combinations for real, only inside 127.0.0.1 of the PC used to write this lab, and checked them against the model. I did not connect to any outside network, and nothing new was downloaded. The queue used in the runs is a very small queue server written for this lab as an http server of Node.js 24.18.0. It puts messages in one array in memory and accepts only two kinds of requests, one that puts a message in and one that takes the message at the head out, and it is not a real message queue product such as Kafka or RabbitMQ (no such product is on this PC and I did not install one). So what this lab shows is the simplest shape of "what a queue does," and it is not a check of how a real product behaves. The program that plays the order server sends the 3 orders one after another, sending the next order after it gets the result of the previous one. In the combinations that use the queue, it sends a put request to the queue server and takes the reply as the result, and in the combinations that call directly, it sends a request to the notification server and takes the reply after handling is finished as the result. The notification server is either an http server that receives direct requests (the direct combinations) or a loop that takes one message at a time from the queue server every 0.1s and handles it (the queue combinations), and either way handling one notification was made to take 0.3s and it handles one at a time. The 0.1s and the 0.3s are values chosen for this lab. In the combinations where the notification server is stopped and starts later, I started the notification server after the results of all 3 orders had been received, and while it was stopped there was no program waiting at that port number. The program that ran made the same text as the code on the screen and read it (how many, whether there is a queue line, how the notification server receives, whether it is stopped and starts later) and started things according to that content. What I compared is the result the order server got (success or failure, and whether it got the result after the notification handling finished or before it finished, judged from the record of the order in which events happened), the handled notifications and their order, and the number of messages in the queue when the notification server starts. I also confirmed that the order of taking out from the queue was the same as the order of putting in, that a request sent directly to the stopped notification server failed every time with a connection refused error (ECONNREFUSED), and that even when I watched for 1s after the notification server started, no notification was handled. In the combination that puts messages in the queue, the queue held 3 messages when the order server got all the results, and this is because of the structure of this run, in which the notification server looks into the queue every 0.1s even when it is running. That the queue was empty when the notification server started is because in this run the notification server was started before the orders. What I checked against documentation is the Introduction of RabbitMQ tutorial 1 (Hello World) (a program that sends messages is a producer, a program that mostly waits to receive messages is a consumer, a queue is like a post box and is in effect a large message buffer, and RabbitMQ is a message broker that accepts and forwards messages) and the Introduction page of the Apache Kafka documentation (https://kafka.apache.org/intro, Main Concepts and Terminology: a producer is a client application that writes events, a consumer is the side that reads and processes events, and the two are fully decoupled and agnostic of each other). I checked the documents through the quotations that WebFetch returned (I did not read the whole pages myself), and there are no section numbers. Much was shortened on the screen. Putting a message in the queue and the queue keeping it were shortened to one request and one reply, and that the reply tells only "it was kept" and not whether the notification was handled is behavior that comes from how this small queue server was made. A real product deals with acknowledgements, with which the side that handled a message tells that it has handled it, keeping the queue on disk, the case where the queue itself stops, the case where a message is lost or delivered twice, the order and distribution when there are several consumers, and redoing a failed handling, and this lab did not look at any of them. Such details are covered in the in-depth labs "Message queue basics", "Kafka partitions and consumers", and "Saga and outbox". This lab also did not judge the standard that separates the jobs a queue suits from the jobs that suit a direct call (whether the result is needed right away). I did not use a browser, and I had only one notification server and one order server.

Previous lab: Caches · Next lab: Deployment