Microservices Architecture, The Hard Parts : Are my services coupled ?

Photo by Growtika on Unsplash

In a Microservices Architecture, services are designed to conceal their internal implementation details and offer a clear interface for communication with other services. Teams work diligently to maintain these interfaces, ensuring they remain stable and backward compatible.

Given this context, you might still ponder: Even if my service’s API interface is well-defined, abstracting internal implementation details and remains unchanged, is my service still coupled with the other services it communicates with?

Indeed, the answer is yes. There exists a dimension of coupling, albeit not static but rather runtime coupling. Let’s elucidate this with a use case of Feed post creation in a Social Networking site —

Feed Service Coupling with Content Moderation Service

1. Feed service manages the feed posts
2. Content Moderation service moderates the feed posts when a new feed post is to be created.
3. Content Moderation service exposes a well defined API interface for Feed service to communicate
4. Feed service communicates in a synchronous blocking request/response pattern with Content Moderation service.

Scenario 1 —

1. User creates a new Feed post through the web or mobile application.
2. The Feed Service receives the request and makes a synchronous blocking call to the Content Moderation service to moderate the post.
3. Content Moderation service responds with a “NO,” indicating the post should be rejected.
4. The Feed Service informs the user about the rejection with an error message.
5. The user revises the Feed post and submits it again.

In this situation, since content cannot be moderated, the Feed service has to respond with a user friendly error — service not available, retry later.

Scenario 2 —

The Feed Service is set up to scale dynamically, with a capacity ten times greater than that of the Content Moderation service. Consequently, if the Feed Service experiences a surge in requests, it can effortlessly expand to manage the increased load. However, the Content Moderation service may struggle to keep up with this demand. This discrepancy can adversely affect the response time for Feed creation, as well as the overall performance and throughput of the Feed Service. In extreme cases, the Content Moderation service may become unresponsive due to the excessive load, resulting in failures in Feed post creation.

In both scenarios described above, the Feed Service relies on the Content Moderation service solely when it receives a request to create a new Feed post from a consumer-facing application. Consequently, the operational behavior of the Feed Service is indirectly tied to the availability of the Content Moderation service. This interdependency is referred to as Dynamic Coupling.

At times, Dynamic coupling is also termed as Temporal Coupling. Here, services enter a temporal coupling only for the duration of the request completion. Once the request is fulfilled, the unavailability of the target service doesn’t affect the calling service.

How about if Feed Service leverages Asynchronous Communication using messages for moderating the Feed post.

Scenario — The Feed Service receives requests from Consumer-facing applications, then dispatches a message to the Content Moderation service via a Message broker. It promptly notifies the user that the Feed post request has been acknowledged and informs them that the post will be published once moderated. In case of an error response from the moderation service, the user is notified of the issue via Email or another appropriate mechanism, enabling them to rectify the situation and resubmit the post.

Feed Service and Content Moderation — Loosely Coupled

Given this situation, will the services be still coupled?

Hmmm…It Depends !!! Asynchronous communication fosters a loosely coupled architecture, yet it hinges on a contract — the message contract. If this contract remains unaltered, it implies loose coupling. However, any modifications to this contract will affect the consumer of the message. Operationally, there will be no impact, and the services will remain loosely coupled. In our use case, the unavailability of the Content Moderation service does not affect the performance or throughput of the Feed service.

If you’re interested in delving deeper into the distinction between synchronous and asynchronous communication in Microservices Architecture, I recommend checking out this blog post:

Microservices Communication : Synchronous or Asynchronous

I trust you now have a clear understanding of what coupling entails within the context of Modern Day Applications built using Microservices Architecture, employing both synchronous and asynchronous modes of communication.

Hope you enjoyed reading this blog. Do share this blog with your friends if this has helped you in any way.

Follow me here on Medium and/or on LinkedIn to read more of such blogs on Microservices, Event Driven Architecture, Kubernetes, DevOps and many more.

Happy Blogging…Cheers!!!

#MicroservicesArchitecture #MicroservicesCoupling #CouplingInServices