Coupling measures how strongly software components or services depend on one another. In a microservices architecture, loose coupling keeps connections and shared information to a minimum, allowing services to change without spreading problems through the application. section 1.14.2
Design for lower coupling by:
- Giving each microservice a clear area of responsibility alongside separation of concerns and high cohesion. section 1.14.2
- Hiding implementation details behind carefully constructed interfaces so storage or other internals can change independently. section 4.4.6
- Recognizing that direct messaging provides immediate responses but tightly couples the sender and recipient; indirect messaging is often preferred when that coupling is avoidable. section 5.6.1
Storage and service communication
A video-storage microservice owns the details of locating and retrieving videos, while a video-streaming microservice streams them to users. Separating these responsibilities lets storage support change without knock-on problems. By contrast, directing a “Viewed” message explicitly to the history microservice and waiting for its response creates tight coupling. section 4.4.6 section 5.6.1
Figure 5.5 A direct message is sent to the history microservice explicitly by its name and is handled immediately.
Use the figure to inspect how explicitly naming and immediately addressing the history microservice creates a tightly coupled interaction. section 5.6.1
