3 ms·
> - you've just made the coupling less robust In my opinion this depends on the use case. If one service has a strong dependency to a different service, it may
by throwaway13623 3y ago
> - you've just made the coupling less robust
In my opinion this depends on the use case. If one service has a strong dependency to a different service, it may be a case of "distributed monolith" and they should consider if the functionality should be moved to the original service instead.
If two services need to communicate with each other, I don't see how a message queue makes the coupling less robust. What is the difference between sending a message or making a http call? You still have a coupling between the two services.
Message queues used right can actually increase operational robustness in my opinion. By placing a message on a queue you get a lot of functionality for free.
- You distribute the load automatically so that the risk of overloading a single instance is reduced
- You can limit the ingestion flow, so that services only process the data at a rate that they can handle
- If a service fails or shuts down, the message remains on the queue for the next instance to retry. You get a lot of retry logic for "free".
- You can easily monitor and scale resources based on the processing rate of the queue itself. Some queues can be allowed to grow large during peek hours, because they can be processed during off hours, while others may require scaling up the service capacity to cover a minimum latency requirement.
Misuse of message queues may of course lead to distributed monoliths and add a lot of complexity in understanding how data flows within the system. This is not something specific for queues and it's the same for direct HTTP calls. As all things, we need to use the right tool for the right purpose.
Actually, one of my pet peeves are internal web hooks. Web hooks are good at notifying an external partner compared to the alternatives, but the complexity is too great to justify its use for internal services as well. Just use a message queue instead for your own services.