Messaging middleware such as queues is mostly redundant. Simplistically -
Client --
If you cache a new submission (message) locally before submitting, you just keep re-submitting until the server returns an ACK for that submission; and your local cache is empty.
Scale clients out as needed.
Server --
If a message is received in good order, return an ACK.
If a message is a duplicate, discard the message and return an ACK.
If a message can only be received once, discard if it already exists on the server, and return an ACK.
If a message is invalid, return a FAIL.
Scale hardware out or up, as needed (ref. "capacity, item 2 in the linked blog post above). Scale queues out by adding service endpoints on the server. Async/await makes the client experience painless. You save your employer $$ because no additional procurement contracts, no licensing fees, no additional server-side infrastructure to run queues, and no consultancy fees to set up and operate Rabbit MQ/Tibco/IBM MQ/Amazon SQS/Azure Queue Storage or whatever other queueing solution the org uses.
Message passing includes concepts auch as durability, security policies, message filtering,delivery policies, routing policies, batching, and so on. The above can support all of that and, if your scenario calls for it, none of it.
The financial argument reduces to dev time vs. procurement, deployment and operational costs of whatever 3rd party product is used, as well as integration, of course.
* I note and welcome the downvotes. However I'd love it more if you'd present a coherent counter argument with your vote.
> If you cache a new submission (message) locally before submitting, you just keep re-submitting until the server returns an ACK for that submission; and your local cache is empty.
This has terrible resource use and offers no visibility into how many clients are waiting. And yet it's still a queue. Why would anyone do that?
I think you have defined "queue" too narrowly in the context of the OP article. MQs are one thing, but the article is about queues as data structures.
A directory of files to be processed may be treated as a queue. Add several directories for different stages of processing, and you have a rudimentary state machine.
Distributed systems in particular may benefit from an MQ, but are by no means necessary.
Generally, when we add an MQ we are really regulating an already existing implicit queue. It's such a common and intuitive data structure that one may easily create one without even realizing it.
Client --
If you cache a new submission (message) locally before submitting, you just keep re-submitting until the server returns an ACK for that submission; and your local cache is empty.
Scale clients out as needed.
Server --
If a message is received in good order, return an ACK.
If a message is a duplicate, discard the message and return an ACK.
If a message can only be received once, discard if it already exists on the server, and return an ACK.
If a message is invalid, return a FAIL.
Scale hardware out or up, as needed (ref. "capacity, item 2 in the linked blog post above). Scale queues out by adding service endpoints on the server. Async/await makes the client experience painless. You save your employer $$ because no additional procurement contracts, no licensing fees, no additional server-side infrastructure to run queues, and no consultancy fees to set up and operate Rabbit MQ/Tibco/IBM MQ/Amazon SQS/Azure Queue Storage or whatever other queueing solution the org uses.
Message passing includes concepts auch as durability, security policies, message filtering,delivery policies, routing policies, batching, and so on. The above can support all of that and, if your scenario calls for it, none of it.
The financial argument reduces to dev time vs. procurement, deployment and operational costs of whatever 3rd party product is used, as well as integration, of course.
* I note and welcome the downvotes. However I'd love it more if you'd present a coherent counter argument with your vote.