I reckon your message broker might be a bad idea

Re:I reckon your message broker might be a bad idea by fallous on Saturday March 29, 2014 @10:37PM (#7494936)

"Used message queue as replacement for RPC service without actually implementing RPC pattern." Key learned from inevitable failure? Message queues are BAD! Except for the part where you weren't actually testing an MQ, you were trying to use an MQ as an RPC service without actually solving the problem and instead insisted on building an RPC service with none of the failure-tolerance of a persistent broker.

I don't disagree with the OP that this is a common mistake, but the solution offered is more of a "we also made this mistake, so clearly it is a problem with MQs and not us!" which isn't actually true.

Additionally, MQs are really (IMO) a better fit for systems that either have a measurable level of complexity on writes or are lightly written but heavily read. You see the same general pattern failure with people who insist that RDBMS is The Answer(tm) even though the data they write/read isn't relational and often read-heavy.

[ Parent | on HN ]

Re:I reckon your message broker might be a bad idea by fallous on Saturday March 29, 2014 @10:47PM (#7494965)

I want to make clear that I'm not intentionally faulting the OP in this situation, because the decision with regards to message brokers isn't easy in a complex system. Often you have to mix "lossy" messages (pubsub) with simple ack messages (receipt confirmation) as well as full RPC-style messaging (receipt ack, result response) and that is usually a non-trivial endeavor from both an architectural as well as implementation standpoint.

[ Parent | on HN ]