Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Can someone provide some rules of thumb regarding when to use Message Queueing and what practical real-world problems they are supposed to address?
Thanks
Asynchronous messaging allows systems to communicate in a disconnected manner. It is not necessary for both systems to be available simultaneously for work to get done.
There are other benefits as well. Often messaging provides a (sometimes unintentional) throttling mechanism. This keeps the receiving system from becoming overwhelmed should many requests all come in simultaneously.
Many messaging systems also provide persistence and reliability facilities, a guarantee that the message will eventually be delivered, even if the messaging platform or receiving system crash.
Message queues also provide a layer of indirection. The system that places a message on a queue does not necessarily know who, if anyone, is receiving the message. The receiver could change in subtle or drastic ways without affecting the sender at all. Loose coupling like this is usually desirable.
Many messaging solutions can participate in transactions as well. This ensures that a system can both receive a message and update a database in response, and know that either both or neither succeeded. If necessary, the receipt of the message can be "rolled back" and retried if a problem occurs.
When you need an asynchronous yet guaranteed way to process stateless, service oriented requests in a tiered environment.
Message Queues provide reliable messaging. They ensure that messages do not get lost completely. They can still be delayed/sent to dead message queues, etc. but they will never completely disappear from the system -- there will always be a copy somewhere, even if it is stuck on the originating client, unless it is explicitly deleted.
Message Queues should be used in situations where loss of a message would be harmful to the business and/or cause system instability. There is an overhead to using them, so they should only be implemented when business requirements dictate.
In situations where they are implemented, there should be some sort of monitoring process put into place that will check for frozen messages (messages that can't be processed because a service is down, the message is incorrectly formatted, etc.) and handle them appropriately.
A message queue is useful to implement load balancing. For example, the server receives "job" messages (orders, status messages ...) and distributes them to all listening clients.
The message queue guarantees that a message will be delivered to exactly one client.
If the clients run on different computers, the total load will be distributed and it will be easy to throw another client to the message load when neccessary, the client just has to connect to the queue and will receive (some of) the messages.
EDIT:
Also good for moving objects between systems (asynchronously). If they are serialized in an platform independent format (JSON, XML), the ojects can even be exchanged between different programming languages.
