I'm exploring the best approaches for microservices to interact with one another. Currently, I'm weighing the pros and cons of gRPC versus REST protocols. However, I'm also rethinking whether these services really need to communicate at all. I'm curious to hear your thoughts on when and how microservices should talk to each other, or if it's better to restructure the design to minimize communication.
1 Answer
Microservices usually communicate either synchronously using something like an HTTP API or asynchronously through an event-based system, like a message broker. Each method has its own benefits depending on your needs.
So, we set up a message queue in a specific service so that we don't lose events, right? Those hardened services seem necessary in case of unreliable connections where retries could be costly.