Message brokers are software services for asynchronous communication between message-oriented microservices (also known as messaging). This type of architecture allows software from different platforms to communicate internally. Message brokers are responsible for validating, storing, routing and delivering messages to the correct destinations, allowing services to send messages without knowing where the recipients are, what their address is, if they are active at that moment and how many of them will consume that message. message. Message brokers normally use a message queue as a way of ordering and storing messages until they are consumed, making sure that nothing is lost or consumed out of order, in addition to being able to guarantee that the message will be delivered only once.
Models of Message Broker
There are different types of message brokers: the peer-to-peer, which delivers the message in a one-to-one relationship (a sender and a recipient), widely used when the message needs to be processed only once and by only one service. In the most commonly used pub/sub model, the publisher can publish a message in message threads and various consumer services can subscribe to these threads to receive these messages. All messages published in a topic are distributed to all services distributed in a topic. To better understand, it is possible to think of this model as a “TV broadcast”, where the signal is received by several televisions.
It's also common to hear two other terms when it comes to messaging: event and command. An event is a message sent by a producer to several consumers about something that has already happened, made available to everyone interested in that event. A command is a direct relationship between a producer and a consumer, which will execute the command that the producer sent. The command is very similar to a queue: the command is sent by a producer and executed by a consumer once.
Message Broker x REST APIs
REST APIs use the HTTP protocol (the standard transport protocol for public networks), and since this protocol works on the request/response pattern, it is used when we need synchronous processing, that is, when the response is needed immediately. If the system being requested is down, an error can occur and the request will not be processed.
Using messaging, an asynchronous communication between services is allowed so that the requesting service does not have to wait for the other service to respond, improving fault tolerance (but not dispensing with error handling and failover methods), ensuring better security, as it guarantees that the message will be delivered as soon as the system is available again. This solution is also known for being scalable and supporting many message subscriptions per second.
Overview between known Message Brokers
There are currently more than 15 different message broker services on the market, but here I will focus on the 3 main ones: RabbitMQ, Apache Kakfa, Amazon SQS.
RabbitMQ is the most widely used open source message broker on the market, lightweight, easy to implement and scalable. It works using commands and does not allow a producer service to publish directly to a queue, being necessary before going through an exchange, a structure responsible for routing the message to the desired queue. It is indicated when there are multiple message producers and only one consumer, since what will get from the queue first is who will consume it and its processing power is lower (approximately 20 thousand messages per second). It is also important to point out that RabbitMQ works with competitive consumers, that is, the consumer that gets the message first will process it and remove it from the queue, without letting other consumers process the same message.
Apache Kafka is made to work with the concept of topics and events, designed for high message processing (approximately 100,000 messages per second), but allowing only primitive data types in key-value format. It is recommended only one producer service and several consumers, and the RabbitMQ calendar, working as a processing pool of the same information by several consumers.
In turn, Amazon SQS (acronym for Simple Queue Service, or simple queue service in literal translation) works similarly to RabbitMQ, offering a simple queue service with low middleware management complexity, without topics, exchanges or anything else. structure type. Its main advantages are the easily configurable asynchronous communication between microservices and ensuring the delivery of messages even if the other service is not available at that time. There is also the Amazon management console, which allows you to monitor and manage your queues. Its limitation is only 300 messages per second, much lower than the other two services. There is a high throughput mode of SQS, bringing that number to 3000 messages per second, yet still not keeping up with the other services. To compensate, SQS is easy to integrate with other AWS services, such as SNS (Simple Notification Service), for example, making it even more interesting to use.
Top comments (0)