Présentation et comparaison des bus de messages vs broker de messages

1. Message broker / bus
Thierry GAYET - 09/2023

2. 2023.09 - Summary for ENENSYS:
RabbitMQ is the selected message Broker
for its software products

3. When a modular brick architecture is available, it is
often necessary to have communication between the
modules. Whether it's a message bus or a broker, the
choice is endless.
GOAL

4. 1. Broker vs bus

5. In the process of evaluating and trialling the introduction of messaging to integrate distributed back-end
services, and other apps, in our system, the question of whether we were aiming to design a Message
Broker or a Message Bus arose. This led to me doing some research to verify and improve my
understanding of the difference.
Firstly, let’s be clear, the terms Message Broker and Message Bus are used in architectural patterns for
messaging systems, also referred to as messaging topologies.Whilst a Message Bus is one such
topology, a Message Broker is only one component in an alternative topology known as Hub and
Spoke.These topologies describe different ways for integrating apps using messaging.

6. Hub and Spoke
In the Hub and Spoke topology, applications are integrated via a central messaging middleware component. Apps send and receive
messages to and from the ‘hub’ only. Senders have no awareness of other apps, or their specific concerns. The hub actively
mediates, or ‘brokers’, all communications between applications, to provide additional integration and messaging services. The hub is
therefore commonly referred to as a Message Broker.

7. Each app is connected to the hub via a ‘spoke’.
These are application-specific protocol and API messaging adapters that are logically part of the hub,
rather than the apps. (The spokes are implemented and deployed as extensions of the hub rather than
apps).
The hub aims to fully decouple apps from one another, such that a sending application has no awareness of either the
number or destination / location of consuming apps.

8. Message Bus
A Message Bus is an architectural pattern that supports integrating apps using a shared (common) set of interfaces. It consists of the
following key elements:
● A shared infrastructure (network and messaging channels) for sending messages to recipients.
● A set of agreed-upon message schemas (message headers, and a common data-model in terms of resources and
representations used in message payloads).
● A set of common command messages. (Used to support the messaging equivalent of RPC to invoke methods in other apps).
When an app wants to send a message it passes it to the message bus, which is responsible for delivering the message to all the other
apps listening for messages on the bus’ shared infrastructure.

9. It’s the apps that are responsible for implementing the common bus Interface.
An app that sends messages through the bus must prepare the message so it complies with the type of
messages the rest of the apps connected to the bus expect.
Similarly, an application that receives messages must be able to understand (syntactically, although not
necessarily semantically) the message types.

10. Similarities and Differences
Diagrams like those above visually distinguish the two topologies. Whilst helpful, they can lead to overlooking the fact that
messaging systems that are based on both topologies have common features. Whilst both topologies have different strengths
(benefits) and weaknesses (liabilities), the primary benefit of both topologies over a point-to-point (direct) integration style is that
they reduce the number of integrations that need to be built to fully integrate all the apps in a system – avoiding “integration
spaghetti”.
Adopting a Message Bus topology implies applications are integrated using a common protocol and they produce and consume
messages that adhere to a common, shared schema, including a data-model (set of resources and their representations). A
Message Bus provides little or no centralised messaging services. Sent messages might only be delivered (broadcast) to all
connected systems. Although pub-sub messaging, another form of message routing, is typically also supported.
A Hub and Spoke architecture integrates apps without enforcing a common API (message schema) on them, and supports
connecting them using disparate protocols. It does so by providing application specific (e.g. protocol) adapters, and an active,
central messaging middleware component. This hub, or Message Broker, understands the messages sent to it, knows which app(s)
the message needs to be sent, and can transform a message to meet the schema expected by each app. Because it brokers
messages sent between apps it can also provide additional messaging services such as message (e.g. content) routing,
aggregation and splitting.
Because a Hub and Spoke architecture provides protocol conversion and data transformation services it supports integrating apps
that can’t be easily changed, such as legacy and third-party apps. A Message Bus based integration does not.

11. Summary and Conclusions
A Message Broker is one part of the Hub and Spoke messaging architecture (topology), as distinct from the Message Bus topology.
These two topologies are both alternatives to point-to-point (direct) integrations, and primarily aim to reduce the number of integrations that need to
be built to fully integrate all the apps in a system – avoiding so-called “integration spaghetti”.
Both topologies have their strengths and weaknesses. One of the main decision points for choosing between them is whether your centralised
messaging infrastructure needs to support integrating apps with disparate protocols and / or message schemas, e.g. because the apps can’t be
changed to support a common messaging interface.
In practice, messaging middleware will vary in the extent of Message Broker features they support, over and above the more basic features seen in a
Message Bus.

12. RabbitMQ : An open-source message broker that implements the AMQP (Advanced Message Queuing Protocol) and is
well-suited for building scalable and robust messaging systems.
Apache ActiveMQ : An open-source message broker that supports various messaging protocols and is often used in Java
applications.
Apache Qpid : A messaging system based on the AMQP protocol, suitable for heterogeneous environments and
interoperability between different platforms.
ZeroMQ / 0MQ : A lightweight asynchronous messaging library that allows you to build distributed applications with low
latency.
Redis Pub/Sub : Redis is an in-memory database that also supports publish/subscribe messaging for building fast and
simple messaging systems.
Amazon SQS (Simple Queue Service) : A fully managed message queuing service provided by AWS (Amazon Web
Services).
Microsoft Azure Service Bus : A managed messaging service in Microsoft Azure that supports messaging and application
integration.
IBM MQ : An enterprise messaging system managed by IBM, formerly known as WebSphere MQ.
HornetQ : An open-source messaging system that supports the JMS protocol and is often used with JBoss Application
Server.
Apache Kafka : While often considered a message bus, Kafka is also used in message broker scenarios for its durability
and ability to preserve message order.
NATS : A lightweight and high-performance messaging system that is designed for simplicity and low latency.

13. RocketMQ : A distributed messaging platform developed by Alibaba Group that provides high availability and scalability.
Mosquitto : An open-source MQTT broker that is commonly used for Internet of Things (IoT) communication and
lightweight messaging.
Beanstalkd : A lightweight and simple message queue system that provides distributed queuing.
NSQ : A real-time messaging platform designed for simplicity and performance.
Kafka Streams (part of Apache Kafka) : Provides stream processing capabilities and can be used for message broker
scenarios where stream processing is required.
ActiveMQ Artemis : An open-source messaging implementation that supports AMQP and MQTT and is designed for high
performance.
Riemann : A distributed event stream platform designed for monitoring and data aggregation.
Google Cloud Pub/Sub : A managed messaging service by Google Cloud that offers scalable and reliable message
delivery.
Kinesis (Amazon) : A managed service by AWS for real-time data streaming and analysis.
DBUS : famous bus developed by Redhat
ABus : yet another breizh bus for embedded platform
Openbinder :
grpc :

14. 2. Bus message

15. Point-to-point messaging
In this pattern, there is one-to-one relation set between the sender and the receiver of the message. Each message
is sent and consumed only once. We can use this pattern for example, when some action needs to be performed
only once.
Now you probably think: “Ok, so what’s the difference between this and some REST API?”. The answer is simple.
The message broker guarantees that message will not be lost in case of failure of the consumer. It’s stored safely in
the message broker queue. We’ll move to that and the other advantages of the message broker later in the article.

16. Message Bus :
● Communication Paradigm : A message bus is typically associated with a publish/subscribe
(pub/sub) communication paradigm. In a message bus, multiple producers (publishers) can
send messages to multiple consumers (subscribers) without knowing the specific
recipients.
● Decoupling : Message buses aim to decouple producers and consumers. Producers don't
need to know who consumes their messages, and consumers don't need to know who
produces them. This promotes loose coupling in distributed systems.
● Scalability: Message buses are designed to be highly scalable, allowing for the addition of
new producers and consumers without significant changes to the system's architecture.
● Examples : Apache Kafka, NATS, Google Cloud Pub/Sub, … are examples of messaging
systems that align with the concept of a message bus.

17. APACHE KAFKA
Apache Kafka is a distributed streaming platform and message broker that is designed for high-
throughput, fault-tolerant, and real-time data streaming. It was originally developed by LinkedIn and
later open-sourced as part of the Apache Software Foundation.
Here are some key features and concepts associated with Apache Kafka:
Publish-Subscribe Messaging : Kafka follows a publish-subscribe model where producers
publish data to topics, and consumers subscribe to topics to receive and process the data.
This decouples producers and consumers, allowing for real-time data distribution.
Topics : Data is organized into topics, which act as logical channels or categories for
messages. Producers send messages to specific topics, and consumers subscribe to topics
of interest.
Partitions : Each topic can be divided into multiple partitions, which allow for horizontal
scalability and parallelism. Partitions are the unit of parallelism and distribution in Kafka.
Brokers : Kafka is a distributed system, and each Kafka server is called a broker. Brokers store
and serve data, and they can be clustered to provide fault tolerance and scalability.
Producers : Producers are responsible for sending messages to Kafka topics. They can be any
application that generates data and wants to make it available to consumers.
Consumers : Consumers subscribe to topics and process the messages. Kafka supports both
real-time and batch processing use cases, making it versatile for various data processing
scenarios.

18. APACHE KAFKA
Message Retention : Kafka retains messages for a configurable amount of time. This allows
consumers to consume data at their own pace, and it also serves as a buffer for real-time data
processing.
Fault Tolerance : Kafka is designed to be fault-tolerant. Data is replicated across multiple brokers to
ensure availability and durability. If a broker fails, consumers can continue to read from other
replicas.
Scalability : Kafka can scale horizontally by adding more brokers to the cluster and distributing
partitions across them. This allows it to handle large volumes of data and high-throughput
workloads.
Streams Processing : Kafka also offers Kafka Streams, a library for building real-time stream
processing applications. It enables complex data processing and analytics on data streams.
Connectors: Kafka Connect is a framework for connecting Kafka to various data sources and sinks,
making it easy to integrate Kafka into existing data pipelines.
Ecosystem : Kafka has a rich ecosystem of tools and libraries, including Confluent Platform (a
commercial offering built on Kafka), monitoring and management tools, and client libraries for
various programming languages.

19. NATS
NATS is a lightweight and high-performance messaging system and message broker that is designed for
simplicity, reliability, and high-throughput communication.
It is often used in distributed and cloud-native applications where efficient and real-time messaging is
critical. NATS stands for "NAT Simple."
Here are some key features and concepts associated with NATS:
Simplicity : NATS is designed with simplicity in mind, focusing on essential messaging capabilities. It
provides a minimalistic set of features to keep communication straightforward.
Publish-Subscribe Model : NATS follows a publish-subscribe messaging pattern where publishers
send messages to subjects (similar to topics), and subscribers express interest in specific
subjects to receive messages.
Point-to-Point Communication : In addition to publish-subscribe, NATS supports point-to-point
communication, allowing a message to be delivered to only one subscriber (queue subscribers)
even if multiple subscribers are interested in the same subject.
Scalability : NATS is known for its ability to handle high-throughput workloads and scale
horizontally. It can be clustered for fault tolerance and to distribute the messaging load.
Lightweight Protocol : NATS uses a lightweight and efficient protocol that minimizes overhead
and reduces latency. This makes it well-suited for scenarios where low latency is essential.

20. NATS Security : NATS offers various security features, including authentication, authorization, and
encryption, to protect communication between clients and servers.
Monitoring and Observability : NATS provides monitoring and observability features,
including metrics and logging, to help operators track the health and performance of the
messaging system.
Client Libraries : NATS offers client libraries for various programming languages, making it
easy to integrate NATS into applications written in different languages.
NATS Streaming : NATS Streaming is an additional layer built on top of NATS, providing
features such as message persistence, at-least-once delivery semantics, and replay of
messages. NATS Streaming is suitable for use cases requiring event sourcing and
message replay.
Cloud-Native : NATS is well-suited for cloud-native and containerized applications. It can be
used in Kubernetes and Docker environments and integrates seamlessly with cloud
platforms.
Community and Ecosystem : NATS has a vibrant community and an ecosystem of tools and
extensions, including NATS JetStream for building modern data streaming applications.

21. Google Cloud
Pub/Sub
Google Cloud Pub/Sub is a fully managed messaging service provided by Google Cloud Platform
(GCP). It is designed to facilitate real-time communication between applications and services in
a distributed and scalable manner.
Google Cloud Pub/Sub is based on the publish-subscribe messaging pattern and offers several
features and benefits:
Scalability : Google Cloud Pub/Sub is built to handle high-throughput, making it suitable for
handling a large volume of messages, even in globally distributed systems.
Reliability : It provides at-least-once message delivery guarantees, ensuring that published
messages are reliably delivered to subscribers.
Durability : Messages published to Pub/Sub topics are stored durably, allowing subscribers to
retrieve messages even if they were offline when the messages were published.
Global Distribution : Google Cloud Pub/Sub offers global distribution of topics and
subscriptions, making it easy to create multi-region or global applications.
Integration : It seamlessly integrates with other Google Cloud services, making it a part of the
broader Google Cloud ecosystem. It also supports integration with external systems
through various client libraries.

22. Security : Pub/Sub offers robust security features, including authentication and access
control, to ensure that data remains secure.
Real-time Processing : It is often used for real-time data processing and event-driven
architectures, allowing applications to respond to events as they occur.
Retained Messages : Messages can be retained for a configurable period, allowing
subscribers to catch up on messages even if they temporarily go offline.
Push and Pull Subscriptions : Subscribers can use either push or pull mechanisms to
receive messages. Push subscriptions allow Pub/Sub to deliver messages directly to
the subscriber's endpoint, while pull subscriptions require subscribers to poll for
messages.
Client Libraries : Google provides client libraries for various programming languages,
making it easy to integrate Pub/Sub into applications written in different languages.
Monitoring and Logging : Google Cloud Pub/Sub offers monitoring and logging
capabilities through Google Cloud's Stackdriver, allowing you to track the health and
performance of your messaging system.
Message Ordering : While Pub/Sub provides at-least-once message delivery guarantees,
it also allows you to configure message ordering, ensuring that messages are
Google Cloud
Pub/Sub

23. 3. Broker message

24. Of course, there are more variations of these patterns. You can have multiple consumers attached to one
message queue. Or you can specify criteria for retrieving only desirable types of messages.
Publish/subscribe
This pattern is slightly different from the previous one. Here, the sender of the message doesn’t know anything
about receivers. The message is being sent to the topic. After that, it’s distributed among all endpoints
subscribed to that topic. It can be useful e.g. for implementing notifications mechanism or distributing
independent tasks. This solution can also lead to implementing an event-driven architecture-based system,
where applications have fewer dependencies between each other.
In this pattern, the components are loosely coupled and transmit events to one another. These events would be
messages sent to the message broker.

25. Message Broker :
Communication Paradigm : A message broker is often associated with a message queuing
communication paradigm. In message queuing, messages are sent from producers to a specific
queue or topic, and one or more consumers process messages from that queue or topic.
Ordering : Message brokers usually preserve the order of messages within a queue or topic,
ensuring that messages are processed in the order they were received.
Point-to-Point Communication : Message brokers are commonly used for point-to-point
communication, where one message is delivered to exactly one consumer (e.g., a worker
process).
Examples : RabbitMQ, Apache ActiveMQ, Apache Qpid, … are examples of messaging systems
that align with the concept of a message broker.

26. RABBIT MQ
RabbitMQ is an open-source message broker software that facilitates communication
between different parts of a distributed application by sending messages between them. It
implements the Advanced Message Queuing Protocol (AMQP) and offers a flexible, highly
available, and scalable messaging system. RabbitMQ is commonly used for building
distributed and decoupled systems, enabling reliable message exchange between
applications and services. Here are some key features and concepts associated with
RabbitMQ:
Message Broker : RabbitMQ acts as an intermediary between producers (senders) and
consumers (receivers) of messages. It receives, stores, and routes messages to
their intended destinations.
Publish-Subscribe Model : RabbitMQ supports a publish-subscribe messaging pattern
where producers publish messages to exchanges, and consumers subscribe to
queues bound to those exchanges to receive messages.
Queues : Messages are stored in queues until they are consumed by subscribers.
Queues are the primary means of communication in RabbitMQ.
Exchanges : Producers send messages to exchanges, which are routing mechanisms
that determine how messages are distributed to queues. RabbitMQ provides several
types of exchanges, including direct, fanout, topic, and headers exchanges, allowing
for various message routing strategies.

27. RABBIT MQ Bindings : Queues are bound to exchanges using bindings. Bindings define the routing
logic that determines how messages are directed from exchanges to queues.
Routing Keys : For certain types of exchanges (e.g., direct and topic exchanges),
messages are routed based on a routing key provided by the producer.
Message Acknowledgment : Consumers acknowledge the successful processing of
messages, allowing RabbitMQ to remove them from the queue. This ensures that
messages are not processed multiple times.
Durability : RabbitMQ can be configured to make exchanges, queues, and messages
durable, ensuring that they are persisted to disk and can survive server restarts.
Dead Letter Exchanges : RabbitMQ provides dead letter exchanges and queues for
handling messages that cannot be processed successfully, allowing you to isolate
and inspect failed messages.
High Availability : RabbitMQ supports clustering, allowing multiple RabbitMQ nodes to
work together to ensure high availability and fault tolerance. Clustering also
enables load balancing and horizontal scaling.

28. RABBIT MQ Security : RabbitMQ offers security features such as authentication, authorization, and
SSL/TLS encryption to protect the messaging system.
Plugins : RabbitMQ supports a wide range of plugins that can extend its functionality,
including support for message transformation, management, and more.
Management and Monitoring : RabbitMQ provides a web-based management interface
and supports integrations with monitoring tools for monitoring and managing the
message broker.

29. APACHE
ACTIVE MQ
Apache ActiveMQ is an open-source message broker and message-oriented middleware (MOM) that
provides reliable, scalable, and asynchronous messaging for distributed applications. It is part of the
Apache Software Foundation and is written in Java, making it compatible with various platforms and
languages. ActiveMQ implements the Java Messaging Service (JMS) API and supports other messaging
protocols, making it a versatile choice for building messaging systems. Here are some key features and
concepts associated with Apache ActiveMQ:
Message Broker : Apache ActiveMQ acts as a message broker, facilitating communication between
different components of a distributed application by routing messages between producers
(senders) and consumers (receivers).
JMS Implementation : ActiveMQ is a JMS-compliant message broker, which means it provides a
standardized API for producing and consuming messages in Java-based applications. JMS allows
for asynchronous and decoupled communication between application components.
Publish-Subscribe and Point-to-Point Models : ActiveMQ supports both publish-subscribe and point-
to-point messaging models. In the publish-subscribe model, publishers send messages to topics,
and subscribers receive messages from these topics. In the point-to-point model, messages are
sent to queues, and consumers retrieve messages from these queues.
Topics and Queues : Topics and queues are the primary means of communication in ActiveMQ.
Topics are used for publish-subscribe messaging, while queues are used for point-to-point
messaging.

30. APACHE
ACTIVE MQ
Message Persistence : ActiveMQ provides message persistence, allowing messages to
be stored on disk. This ensures that messages are not lost in case of system
failures or restarts.
Message Acknowledgment : Consumers acknowledge the successful processing of
messages, which allows ActiveMQ to remove them from queues or topics. This
ensures that messages are not processed multiple times.
Message Filtering : ActiveMQ supports message filtering and selectors, enabling
consumers to specify criteria for receiving specific messages.
High Availability : ActiveMQ can be configured for high availability and fault tolerance
by setting up master-slave configurations, network of brokers, or clustering. This
ensures message delivery even in the presence of broker failures.
Security : ActiveMQ offers security features such as authentication, authorization, and
SSL/TLS encryption to protect the messaging system.
Transport Protocols : In addition to JMS, ActiveMQ supports other messaging
protocols, including the Stomp, AMQP, MQTT, and WebSocket protocols, making it
interoperable with a wide range of clients and platforms.

31. APACHE
ACTIVE MQ
Plug-ins and Extensibility : ActiveMQ can be extended with various plug-ins and
features, such as message transformation, message conversion, and custom
authentication.
Management and Monitoring : ActiveMQ provides a web-based management console
and supports integration with monitoring and management tools for monitoring and
managing the message broker.
Client Libraries : ActiveMQ offers client libraries for multiple programming languages,
enabling developers to integrate with the message broker using their preferred
language.

32. APACHE
QPID
Apache Qpid is an open-source messaging system and message broker that is designed for
facilitating communication between applications and services in distributed systems. It is part of
the Apache Software Foundation and provides a reliable and scalable messaging infrastructure
for various use cases. Apache Qpid is based on the Advanced Message Queuing Protocol
(AMQP) and offers several features and components for building messaging solutions. Here are
some key features and concepts associated with Apache Qpid:
Message Broker : Apache Qpid acts as a message broker, serving as an intermediary for
sending and receiving messages between different components of a distributed
application.
AMQP Implementation : Qpid is known for its compliance with the AMQP messaging
standard. It supports multiple versions of the AMQP protocol, making it interoperable with
other AMQP-compliant messaging systems and clients.
Publish-Subscribe and Point-to-Point Models : Qpid supports both publish-subscribe and
point-to-point messaging models. In the publish-subscribe model, publishers send
messages to exchanges, and subscribers receive messages from queues bound to these
exchanges. In the point-to-point model, messages are sent directly to queues for
consumption.

33. APACHE
QPID
Exchanges and Queues : Exchanges in Qpid are responsible for routing messages to one
or more queues. Queues are used to store messages until they are consumed by
subscribers.
Message Persistence : Apache Qpid provides message persistence, allowing messages
to be stored on disk. This ensures that messages are not lost in the event of system
failures or restarts.
Message Acknowledgment : Consumers acknowledge the successful processing of
messages, allowing Qpid to remove them from queues. This ensures that messages
are not processed multiple times.
Message Filtering : Qpid supports message filtering and selectors, enabling consumers
to specify criteria for receiving specific messages.
High Availability : Qpid can be configured for high availability and fault tolerance through
mechanisms like message replication, failover, and clustering. This ensures message
delivery even in the presence of broker failures.
Security : Qpid offers security features such as authentication, authorization, and
encryption to protect the messaging system and messages in transit.

34. APACHE
QPID
Transport Protocols : In addition to AMQP, Qpid supports other messaging protocols, including the MQTT
and WebSocket protocols, making it versatile for different types of clients and scenarios.
Management and Monitoring : Qpid provides management and monitoring tools and interfaces, including a
web-based management console and integration with monitoring solutions.
Client Libraries : Apache Qpid offers client libraries for multiple programming languages, enabling
developers to integrate with the message broker using their preferred language.
Pluggable Architecture : Qpid's architecture is designed to be extensible, allowing users to plug in custom
components and extensions for various needs.

35. How do message brokers work?
Before we start let’s get through some basic concepts of a message broker:
● Producer – the application responsible for sending messages. It’s connected with the message
broker. In publish/subscribe pattern (we’ll move on to that) they are called publishers.
● Consumer – the endpoint that consumes messages waiting in the message broker. In
publish/subscribe pattern they are called subscribers.
● Queue/topic – a folder in a filesystem. Message broker uses them to store messages.
There are two particularly popular distribution patterns for message brokers. Let’s take a look at
them.

36. What are the advantages of using the message broker?
Provided communication between services that may not be running at the same time. The producer can send
messages regardless of whether the consumer is active or not. All it needs is a running message broker. The same
applies to the consumer.
Improved system performance by introducing asynchronous processing. High-consuming tasks can be distributed to
separate processes.
That will fasten up your application and increase user experience. Increased reliability by guaranteeing the
transmission of messages.
Message brokers offer a redelivering mechanism. In case of consumer failure, it can redeliver the message
immediately or after some specified time. It also supports routing of not delivered messages – it’s called a dead-letter
mechanism.
That sounds good, but there is no solution without drawbacks. Message brokers are no exception.

37. What are the disadvantages of using the message broker?
Use of the message broker involves asynchronous processing. Therefore, the disadvantages of using it are related to the
challenges we face by using asynchronous calls.
Increased system complexity. Introducing a message broker in your system is a new element to your whole system
architecture. Because of that, there are more things you have to take into account, such as maintaining the network between
components or security issues. Additionally, a new problem arises related to eventual consistency. Some components could
not have up-to-date data until the messages are propagated and processed.
Debugging can be harder. Let’s say you have async multiple stages of processing a single request using the message
broker. You send something but did not receive a notification. Searching for a cause of failure can be a challenge as every
service has its own logs. Keep in mind to add some message tracing facilities alongside implementing systems using
message broker.
There’s a steep learning curve at first. Message brokers are not trivial as they sound. They have a lot of setup and
configuration options. The size of queues and messages, the behavior of queues, delivery settings or messages TTL, are
only a few of many options you can set.
Not that we know the theory behind message brokers and familiar with both the good and the bad of this approach, we can
get to the fun part – using message brokers in practice!

39. REDUCE PRESSURE OFF DOWNSTREAM CONSUMERS
● Many people use message brokers to reduce back pressure from downstream
services. The sender puts messages on the queue, and consumers can pick up
these messages and process them in the batch size they want and the time they like.
● You can use message brokers to make sure that downstream services do not get too
overloaded, which can improve system reliability.
● Example of this could be to use an SQS queue, to handle many messages, and a
consumer to process these messages and delivery information to a third-party API.

40. PREVENT MESSAGES/DATA BEING LOST
● Many brokers offer the ability to retry messages/events if they fail to get processed or
delivered. This can help prevent any information being lost.
● If your broker does offer retry and replay, you want to consider idempotency as your
consumer may be triggered more than once, and you don’t want any unwanted side
effects.
● This could be a great pattern, as you broker may do the heavy lifting for you
(retry/reprocess), many are configurable and if all fails you can decide what you want to
do with the messages after the retry period (example drop them or store them for
later processing)

41. PARALLEL PROCESSING
● Some brokers offer pub/sub patterns allowing you to send events and notify
downstream consumers. This pattern allows you to notify downstream processes
that something has happened. Many downstream systems can listen to these
events.
● If you are using message queues, you can still have many consumers processing
messages from the queue, this allows you to scale processing downstream.

42. REDUCING KNOWLEDGE OF SYSTEMS
● Using messages/events to communicate between systems/services can help us
decouple our architecture.
● Producers may not need to know about downstream consumers, this gives the
producers the ability to isolated and focus within its own domain/boundary.

43. 4. Comparison

46. 5. OTHER LINKS

47. ABUS :
https://drive.google.com/file/d/1WDnbt9IcErOKfLfHUDOR0uUS9P91CfqX/view?usp=drive_link
https://drive.google.com/file/d/1wcRXoYP93Hmy189CUCTzXe85YQQedBCm/view?usp=drive_link

48. QUESTIONS & ECHANGES