Message queue is a single point of failure because once the connection to the queue/broker itself is down. All services are basically isolated and can't communicate with each other.

Melvin Koh depends on the definition of message queue. Usually it's a queue so a FiFo structure that contains 'messages' as some kind of Buffer/Cache/DB depending on the persistence definition. the level of distribution, isolation, sharding, p2p or other implementations are up to the implementing party and restricted by the protocols.

In other word you can basically have a local p2p torrent like system where you replicate your message/queues to at least N/2 shards. Just top of my head not even considering the other complications like quorums, source of truth. Also the question is about what you can communicate ... anyhow I am pretty sure you considered all this stuff as well :P just wanted to sound smart in my lunch break ;)

Message queue is a single point of failure I would really say the opposite. When you plan for production, your message queue will need to support somne sort of clustering for dealing with failure. For instance (because AMQP was mentioned) RabbitMQ offers tons of knobs to control your durability/replication vs performance, and it’s one of the most stable pieces of infrastructure I ever had to maintain in production. But others solutions (MQTT, Kafka, ...) are there really to give you a durable and resilient central bus.

In my opinion though, I would consider messages bugs (or distributed logs) in a separate category than RPC or transaction-based things like REST. Message queues are really interesting when you want to decouple the load or parallelize task (you can build really awesome topologies with Rabbit or Kafk), to make the public-facing (with many definitions of public) endpoints as lightweight as possible, and smooth out and parallelize the work at the other end with workers. What I mean is that both have strengths, and should be used depending on the context. And as your platform grows, it might make sense at some point to use more than one paradigm.