>No, the whole issue was caused by using message queue where you shouldn’t use them or in a way…
Tony Weston

>This is a simple problem, which a message queue can be used to solve. What type of problem is there that isn’t like this pub/sub kind of use case that I suggest?

Message queues are good at being dumb message pipes. They are something you should not use if you want to supersede existing message by another one. For that you need a storage that you can query for data. This problem (is there a message in queue for the customer I want to update? If it is, update it instead of appending another message) sounds like a database, not message queue, and is perfectly solved by databases — most likely relational ones, because it requires single consumer. For the cases where messages are independent of each other, message queues work great.

> The Customer service needed to know about ‘Order messages’ and how to decode them anyway.

That is one thing it needs to know — how to talk to mq server. It *does not* need to know how to talk to other services. It does not need to know who produces the messages its consuming. This removes *a lot* of complexity. None of the services communicating via mq have to deal with storing data — which they would have to, if you force them to know “how many orders were processed in last hour”. Such storage would also become a bottleneck. Your suggestion requires adding huge amount of dependencies and complexity, that message queues were designed to remove.

Show your support

Clapping shows how much you appreciated Maciej Dziardziel’s story.