3 ms·
This is magic as far as I can tell... How can this be so far ahead of everything else out there?! Anyone have any insights on how this works and what the perfor
by zaptheimpaler 14y ago
This is magic as far as I can tell... How can this be so far ahead of everything else out there?! Anyone have any insights on how this works and what the performance/flexibility tradeoffs are for this magic?
- deleted 14y ago[deleted]
- paulhodge 14y agoIt'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..
- zaptheimpaler 14y agoThank you for the explanation, this is blowing my mind because I had no idea message queues existed! Given that, this is a great abstraction for RPC on top of an MQ.