Nice & comprehensive overview of one of my favourite topics, message oriented middleware (MOM), thank you Assyahid. :-)
Just some remarks from my side:
RabbitMQ is far from being one of the first brokers. Messaging was invented and/or became popular in the 90's with IBM MQ and several JMS implementations. However RabbitMQ might be one of the earliest free message brokers (together with ActiveMQ).
While the 1:1 pattern makes use of queues (where messages are just being queued), I would suggest to explain the 1:n pattern with topics and subscriptions (publish/subscribe). Kafka works that way. RabbitMQ is a bit more complicated, but also doesn't just use queues for 1:n message routing, but introduces exchanges for that matter. I think exchanges are specific to RabbitMQ, at least I haven't seen them anywhere else, so the more popular 1:n implementation is definitely publish/subscribe.
One of the best features of Kafka is its ability to replay messages. It is based on Kafkas append-only log with pointers to the last message that has been fetched from each subscriber. So while message brokers were initially not designed for persistency, Kafka has indeed managed to provide a pretty good persistency. However there's no good way to query data, because Kafka has no idea of the data structures in the messages, so in the end it's still a bad way to persist your data and should only be used additionally (e.g. for streaming) to a database.
I wouldn‘t agree on the last part regarding querying kafka. You can make use of the schema registry and describe the events structure so they can be easily queried (e.g. via ksqldb).
very good answer, thank you for providing additional opinions on the topic of discussion of messages broker , I am very happy if someone provides additional opinions because it can open one's view to the development of microservices
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice & comprehensive overview of one of my favourite topics, message oriented middleware (MOM), thank you Assyahid. :-)
Just some remarks from my side:
RabbitMQ is far from being one of the first brokers. Messaging was invented and/or became popular in the 90's with IBM MQ and several JMS implementations. However RabbitMQ might be one of the earliest free message brokers (together with ActiveMQ).
While the 1:1 pattern makes use of queues (where messages are just being queued), I would suggest to explain the 1:n pattern with topics and subscriptions (publish/subscribe). Kafka works that way. RabbitMQ is a bit more complicated, but also doesn't just use queues for 1:n message routing, but introduces exchanges for that matter. I think exchanges are specific to RabbitMQ, at least I haven't seen them anywhere else, so the more popular 1:n implementation is definitely publish/subscribe.
One of the best features of Kafka is its ability to replay messages. It is based on Kafkas append-only log with pointers to the last message that has been fetched from each subscriber. So while message brokers were initially not designed for persistency, Kafka has indeed managed to provide a pretty good persistency. However there's no good way to query data, because Kafka has no idea of the data structures in the messages, so in the end it's still a bad way to persist your data and should only be used additionally (e.g. for streaming) to a database.
I wouldn‘t agree on the last part regarding querying kafka. You can make use of the schema registry and describe the events structure so they can be easily queried (e.g. via ksqldb).
very good answer, thank you for providing additional opinions on the topic of discussion of messages broker , I am very happy if someone provides additional opinions because it can open one's view to the development of microservices