When Should You Use a Message Broker for Microservices?

A good rule of thumb is to implement a message broker when A to B connections can’t handle the demand and start failing—like when service B is overloaded and causes issues for A. It's best to predict this before you hit a breaking point.

Ultimately, consider whether using a message broker makes your architecture cheaper, safer, or more reliable. Focus on achieving your goals rather than sticking to prescribed rules that may not apply to your specific situation.

When designing your microservices, think about their communication patterns from the start. A successful microservice should have a clear purpose, be loosely coupled, and be capable of scaling independently. I generally lean toward asynchronous communication with message brokers because they help avoid tight coupling, which can cause chaos down the line if you're not careful. Just keep in mind the importance of data management and the potential risks of stepping into a distributed monolith as you scale.

It really depends on how the services communicate—whether it's stateful or stateless, and if the communication is synchronous or asynchronous. Message queues shine when you need to send messages without waiting for an immediate response, letting you move on to other tasks. If you have to wait for a response before continuing your work, a direct API call might be the better choice.