There are many brokers that we could consider using when building an Event Driven Architecture. Do we go with Kafka, RMQ, Pulsar, NATS to name but a few? Vendors make bold claims, promising that their broker alone is adequate to form the digital nervous system for your architecture. What should you do?

In this session we argue that one type of broker may not meet all our needs. Akin to polyglot programming - picking the best language for the job - or polyglot persistence - picking the best language for the job - when using Polyglot Flow we pick the best broker for the job.

We will look at the different protocols for messaging: series and discrete and understand their different characteristics with examples in RMQ and Kafka. We will also look at the functionality that brokers may have such as dynamic routing, requeue and dead letter queues, delay queues, and consumer groups and the scenarios that we enable with them. We will look at the ecosystem that surrounds that broker, such as support for aggregation and filtering. Finally, we will consider the environment - how does running on Kubernetes impact your choice of broker?

We will then ask the question, how do you evaluate your architure's needs to determine which characteristics you need and thus what is the smallest set of brokers you can pick to meet them, without having to work around the limitations of any one broker.

By the end of the session you should be able to understand if you can survive with a monoculture, or if you need to embrace Polyglot Flow.