[carc]

A couple of big reasons don't like message buses (but open to hearing about why I'm wrong):

-All "requests" will succeed even if malformed

-Couples producers/consumers to the bus (unless you put in the extra work to wrap it in a very simple service)

[GordonS]

> -All "requests" will succeed even if malformed

Took me a minute to grok this, but I think you mean, message bus clients can send 'any old shit' and the broker will happily queue it?

A lot of the more 'managed' (abstracted) clients in the statically typed world deal with this by structuring queues by the object type/interface. A bad actor could probably circumvent this if they really wanted, but for normal usage it will at least ensure that objects sent are of the expected type.

This means that in real-world usage, this isn't an issue.

[opportune]

The fix to A is client side filtering. That can be hard to set up if you don't enforce it to begin with. I'm currently dealing with poor/no client side validation at work and it does become a complete fucking pain dealing with poor upstream schema hygiene

I don't see why the second point is a bad thing, at all. Message buses are meant to provide a non urgent abstraction layer to simplify the relationship between producers and consumers (if you need urgency, don't use a message bus). It simplifies load balancing the consumer stage and doesn't impose any limits on producers (many of which can be clients released into the wild).

[EdwardDiego]

> All "requests" will succeed even if malformed

A good pattern is to use a schema to verify you're sending valid data in the producer (at the very least, in a unit test, if not at runtime) - for example, the Confluent wrapped Kafka ships with a schema registry and painless Avro based Kafka producers

If overhead in the producer is stopping you from validating each record at creation time, then you can validate downstream, so long as your consumers agree to only consume the validated data.

[GordonS]

> Couples producers/consumers to the bus (unless you put in the extra work to wrap it in a very simple service)

This is an area where adding a simple layer of abstraction is a good thing - most times, all you want is something like a `Send<T>`/`Send(obj)` method, which really will translate fairly universally across message busses.

I used such a thing recently, switching out RabbitMQ for MQTT - all I really had to do was point to a new implementation of the interface!

[ww520]

- The consumer needs to validate the incoming requests. Just like any input sources, the incoming data cannot be trusted until validated.

- You need coupling somewhere anyway. Moving the coupling to the bus let the consumer and producer evolve more freely.

[jeremyjh]

> - The consumer needs to validate the incoming requests. Just like any input sources, the incoming data cannot be trusted until validated.

That's correct. And the producer will be long gone by the time the consumer attempts to validate that message and rejects it.

[teyc]

indeed. Here's an example of a case against messaging in distributed systems design. https://www.brisbanetimes.com.au/national/queensland/educati...

A synchronous call would have failed when the operator issued the request, and the onus is on the operator to find alternate ways of contacting the police.