3 ms·

With your http example you have to know who the recipient is. If there are multiple recipients then you’d have to call each one. With a queue you don’t need to

With your http example you have to know who the recipient is. If there are multiple recipients then you’d have to call each one. With a queue you don’t need to know, and the recipients can subscribe to information on the queue themselves. Especially useful in event-driven architectures. Push vs pull.

brundolf 4y ago
I guess. Maybe I'm not thinking on the right scale of company, where there may be many services run by many teams that don't talk to each other. In that case I could see decoupling between senders and consumers being helpful
- virtual_void 4y ago
  It’s not just about scale though, it can be useful where you own both components. The producer just produces events, as long as the queue is available. no retry is needed if the other side is having a problem or being updated. The messages sit in the queue until the other components can consume them. Especially useful when producer and consumers are running at different rates and the queue becomes a buffer. There’s also a difference in making a command to another service vs event or state notification. In the case of a command you often want to wait and find out if it went ok. Events or states published onto a queue are more of a case of “here is a thing that happened, deal with it how you wish”
- xorcist 4y ago
  Scale isn't the point. It's the nature of event based systems. Why do we have interrupts? Having an abstraction there makes developing operating systems easier. Why do we have hooks in git? Because we want to add or remove software integrations at run time, without touching git itself. Queue based systems have similar characteristics as event based systems. It's not a bad idea at all, you probably use message based systems every day without thinking about it, culturally however the idea is irresistible for enterprise developers who live for abstractions. Just something to keep in mind.

brundolf 4y ago

I guess. Maybe I'm not thinking on the right scale of company, where there may be many services run by many teams that don't talk to each other. In that case I could see decoupling between senders and consumers being helpful

virtual_void 4y ago
It’s not just about scale though, it can be useful where you own both components. The producer just produces events, as long as the queue is available. no retry is needed if the other side is having a problem or being updated. The messages sit in the queue until the other components can consume them. Especially useful when producer and consumers are running at different rates and the queue becomes a buffer. There’s also a difference in making a command to another service vs event or state notification. In the case of a command you often want to wait and find out if it went ok. Events or states published onto a queue are more of a case of “here is a thing that happened, deal with it how you wish”
xorcist 4y ago
Scale isn't the point. It's the nature of event based systems. Why do we have interrupts? Having an abstraction there makes developing operating systems easier. Why do we have hooks in git? Because we want to add or remove software integrations at run time, without touching git itself. Queue based systems have similar characteristics as event based systems. It's not a bad idea at all, you probably use message based systems every day without thinking about it, culturally however the idea is irresistible for enterprise developers who live for abstractions. Just something to keep in mind.