when is messaging (JMS based brokers/queues) an overkill?

JMS based brokers are a very useful tool to decouple systems. However, invariantly the thin line between architecture and bloat is crossed. As someone with theoretical understanding of brokers, but without the practical experience, what advice can I be given to avoid "bloat". What are the performance factors, design considerations and systems characteristics should one be aware so that brokers are not mis-used. e.g开发者_运维百科. using brokers for pushing events to a logging service seems an overkill (one of my friends actually almost suggested that). Another example - when creating an auditing service (auditing for multiple backend systems), is (asynchronous) messaging a good solution. pros and cons?

---

It's all a question of scale.

As long as you have few services, all running on the same box, or maybe several boxes but all communicating just with a database, then messaging doesn't solve any real problem and only adds complexity.

Once you have many services, running on multiple servers (and possibly multiple data centers), that need to communicate with each other (and not just with a database), messaging becomes necessary.

Another case is when your services have different release schedules, especially when there are many and they're developed by different teams. It gets to a point where synchronize releases to ensure compatibility and minimize down-time becomes a real burden. Asynchronous messaging is part of the solution there.

Finally, pushing asynchronous events to a logging service does make sense, given the conditions mentioned above. If you have multiple services running on multiple servers using some company-wide logging service, then a log queue makes perfect sense.