Azure Event hub and Kafka .. are not message queue.

A real queue have an API similar to JMS, ex rabbitMQ, IBM MQ, Microsoft MQ, …

The difference is you have a mailbox of message from which you remove messages you have consumed by acknowledging reception. Message will be sent to subscribers until they are acknowledged.

So publisher write message m1, m2, m3

subscriber receive m1, m2,m3 and ack only m3.

it will later receive m1 and m2 again but not m3.

Kafka is more like tcp It’s a stream.

You probably don’t need a separate message queue service if you have a transactional (probably “real SQL”) database. The “table as queue” pattern in SQL has been used since the 1970s at massive scale and was taught in my CSE 100-level classes back in the 1990s. The natural API for such a thing is basically the same as Rabbit/Kafka//SQS/whatever.

The ”massive scale” of the 1970s is very far from today’s ”ordinary scale”! Just saying that this approach really does not scale well and problems will start around high hundreds of thousands to low millions of messages queued.

i agree with you if you have a transactional SQL it’s usually best to stick to this until it doesn’t scale.

it allows you to make the « add message to queue » part of a transaction that update other table which is nice!

do you have any pointers? Just curious how this is taught in the old days