Yazının Türkçe versiyonuna bu link aracılığı ile ulaşabilirsiniz.
Message broker is a component used for applications to communicate with each other. It provides the exchange of information between applications by transmitting messages received from the producer to consumer.
Queue is a form of data structure. You can think of this structure as a real life bank queue, queues created to buy movie tickets et cetera. The first to enter the queue will be the first to receive the service. The reason we briefly talk about this data structure is that the message broker mostly built on this data structure. For this reason, even though message broker and message queue are not the same thing, they are often used interchangeably. The best example of this will be the RabbitMQ message broker. MQ letters at the end of RabbitMQ mean message queue.
Producer: It is the component from which the messages are produced. For example; when you create an account on a website, UserService creates a message indicating that the user has been created and forwards it to the message broker. In this example, UserService takes on the role of the producer.
Consumer: It is our component that tracks the messages coming to the queue. It receives messages from the queue and executes actions. If we use our previous example, we can imagine that we have a service that sends “Welcome” mail by reading the user has been created message through the broker. Our service that carries out the action, that is, sends the mail, is the consumer in this example.
Message broker: It is the component that receives the messages from the producer and transmits them to the consumer. It transmits the message to the required queues according to its rules. It also delivers the message to the consumer through these queues. Components such as Kafka, RabbitMQ, ActiveMQ play the role of message broker.
How Message Broker Works?
The producers transmit their messages to the component called exchange in the message broker with the specified protocols. We can think of exchanges as entry points for message brokers. Exchange is responsible for forwarding messages to the required queues according to the specified rules. In the correct usage of the message broker, messages are not directly sent to the queues.
Consumers are also in communication with the message queues. We can think of the queues as the broker’s exit points.
RabbitMQ operates with a structure very similar to this topology. Each consumer has its own queue. Samples of messages sent on exchange are stored in these queues. When the consumer finishes the transaction, the message is removed from consumer’s queue. Because another consumer does not read a message through the queue that belongs to someone else.
Kafka presents the above topology with a slightly different structure. The messages are not in separate queues. On the other hand, consumers determine where they stay on message queues with their own pointers. After the consumer processes a message, it moves its pointer. The messages are not deleted from the queues because another consumer can also process this message. It acts as if there are more than one queue by using pointers.
What are Exchange Types?
Direct and fanout are the most used types. The type is decided according to the number of queues that can communicate with exchange.
- If the exchange is set up to communicate with only one queue, this exchange is called direct-exchange.
- If more than one queue is connected to an exchange and copies of incoming messages are distributed to these queues, we are using the fanout-exchange type.
What Are the Advantages of Using Message Broker?
Messaging systems are generally scalable systems. As your load increases, it is easy to deal with this load by allocating the necessary resources to your messaging system.
Messaging systems can be used to develop different applications with loosely coupling. For example; billing processes can be triggered that will start with the completion of the purchase through the message broker. In this way, an order management application and an accounting application can be developed separately since they do not communicate directly with each other.
The contribution of the messaging system is also very high in terms of using resources more efficiently. Let’s assume that we received a request from the user and that we were making a heavy transaction. In this case, we need to use powerful machines to avoid waiting for the user for a long period of time. However, if we do not have to respond instantly, we can give an answer that the request has been received without executing the action. In this way, our response time will be shorter. Also, since we have created an asynchronous process, we have the opportunity to fulfill the demand with lower powered machines.
What are the Message Types?
We can talk about two types of messages; event and command.
Event messages are messages that are sent to the messaging system to announce to all applications that an event has occurred. It is recommended that the message names end with a past tense suffix, as they are published after the event is completed. A message called PackageDelivered can be an example. Event messages are forwarded to fanout-exchange, as they will be transmitted to the entire system. Communication with the message broker is done with the publish method because the message spreads throughout the system.
Command messages are messages sent to the message broker to trigger the consumer to fulfill a request. It is recommended to include the verb of the process to be executed in the name of the message. The message named CreateAccount can be an example of a command message. Command is processed by a single consumer. For this reason, command messages are transmitted to direct-exchanges. Communication with the broker is carried out by the send method. Because in this case, it is defined to whom the message will be delivered. In this type of message, message is sent to a particular receiver rather than being published to all processes.