Using microservice architecture creates thrilling opportunities for companies. For development teams, it means that they get to do interesting things with the newest, shiniest tools and frameworks as they deliver innovative new experiences to their customers.

However, when you first read about all the advantages of having microservice architecture with breathless speed and excitement, it can feel like there is not a lot of room for error. In real life, these thrilling opportunities can’t exist without having a good architectural design, and you know (or at least, you should) that your future success depends on the design of the microservice architecture.

There is an important principle called loose coupling, which states what the development teams must achieve to be able to have a successful microservice architecture design. In this post, I will delve a little further into that principle.

The idea behind microservice architecture is simple: To develop and build a large system, you have to decompose its functions into relatively small, single-purpose, and loosely coupled services

Loose coupling

A loosely coupled system is one in which each of its components has, or makes use of, little or no knowledge of the definitions of other separate components. Subareas include the coupling of classes, interfaces, data, and services. Loose coupling is the opposite of tight coupling.

In short, loose coupling in microservice architecture means microservices should know little about each other, and any change to one service should not affect the others.

Why is loose coupling so important in microservice architecture?

  • When microservices are not split in the right way, this creates tightly coupled microservices that will have all the disadvantages of a monolith and all the complexities of microservices, aka a distributed monolith. An architecture that accomplishes loose coupling has several advantages, for instance:
  • Loosely coupled services increase the evolvability, encourage multiple changes, and new solutions, especially in situations in which the system should be able to adjust to environmental changes. As we all know; in software development, everything changes all the time!
  • Loosely coupled services increase the optimum efficiency of the architecture. It enables us to break or reconfigure the link between services. Therefore it also reduces the coordination cost.
  • Having loose coupling in services increases the agility, which allows you to iterate on a small, focused piece of functionality quickly, yielding equally quick results.
  • Loose coupling allows changes to be deployed independently, which increases deployability.
  • The service independence removes impediments when waiting for the other service implementation(s). This way, we will have the frequency and stability of deployments, increasing our productivity.

Synchronous vs asynchronous interactions

Microservices need to effectively communicate with each other. This might require using a synchronous call such as REST or gRPC or an asynchronous call with a messaging system (Event-driven Architecture), such as RabbitMQ, Apache Kafka, etc.

Synchronous interactions tend to dominate the closer you get to a user (like with a website), while asynchronous service interactions become the rule if there is any work that can be deferred. The deferred work will be processed as soon as it is convenient to do so.

People often focus on the synchronous aspect of a system when developing microservices, but the asynchronous side deserves attention as well.

Synchronous communication between microservices causes a coupling to be too tight. In a tightly coupled system, the performance of the system is mostly determined by its slowest service. That’s why, for a long-term solution, it is recommended that microservices should communicate asynchronously. If a service makes a call to another service synchronously via HTTP-based API and that service makes a call to another service or multiple services, and then maybe some of these services make a call to yet another service and so on, then latencies are added up.

On the other hand, asynchronous communication, like in event-driven architecture, allows services to collaborate by publishing and consuming events. In this context, an event describes a simple change in state. A service can broadcast events to one or more consumers without needing to know who might be listening and how they might be responding.

This approach encourages loose coupling between the services by enforcing an indirect style of collaboration where services don’t need to know about each other. The sender doesn’t care who is receiving the event, while the consumer doesn’t necessarily care who sent it.

Services that are integrated via asynchronous event streams, tend to scale better than those that use direct API calls. This also improves resilience as service outages are less likely to give rise to cascading failure.

Conclusion

Loose coupling is one of the most important principles in a good microservice architecture. Although loose coupling offers all these benefits, in practice it’s not easy to attain. Of course, we can’t eliminate all coupling in the system, some of them are perfectly fine as long as they don’t weaken the desired outcome.

For a scalable, resilient microservice architecture, we should ensure loose coupling, so that we can reach our ultimate goals and be able to:

  • deploy an independent service that doesn’t affect the others
  • test and verify our service without using an integrated environment
  • keep other services running if one stops