It's not that magic; this kind of development is what message queues have been enabling for years (ActiveMQ, ZeroMQ, RabbitMQ, etc). It's a nice way to architec

It's not that magic; this kind of development is what message queues have been enabling for years (ActiveMQ, ZeroMQ, RabbitMQ, etc). It's a nice way to architect systems. Bridge looks like a nice evolutionary step forward, in terms of elegance & consistency. Message queues aren't a silver bullet of course, they introduce a lot of potential problems which need to be solved on a case-by-case basis. Such as, what happens if a receiver dies before handling a message? Do senders need to retry sending messages or can they fire-and-forget? Is retrying built in to the queue layer? What happens if a receiver is bogged down with too many messages? Is there a limit on the incoming queue size and what is the limit? Can we start dropping messages if we're overloaded; which messages can we drop? If you make a request that expects a reply, should you timeout and what timeout duration should you use? When a new handler joins the system, should they instantly receive messages that have been waiting for them, or should they dump the existing queue? And so on..