Maybe you have, at least heard something about building decoupled things in the software world: decoupled classes, decoupled modules, and also decoupled services. 

But what does it mean for a software unit being decoupled from another? 

In a practical way, two things are coupled when any changes made to one of them requires you to also change the other one. For example, if you have a method that returns a String and changes it to return a Double, all the methods calling that one are required to be changed.

There are levels of coupling. For example, you could have all your classes and methods very well designed for loose coupling, but they are all written in Java. If you change one of them to .NET and would like to keep all of them together (in the same deployment package), you need to change all the other ones to the new language.

Another thing to mention about coupling is how much one unit knows about the other one. They are tightly coupled when they know a lot about each other and they are the opposite, loosely coupled, if they know a little or almost nothing about each other. This point of view is related mostly to the behavior of two (or more) parts. 

The last way to look at coupling is in terms of a contract. If changing the contract breaks the clients, they are tightly coupled. If not, they are loosely coupled. That's why the best way to promote loose coupling is using interfaces. As they create contracts for its implementers, using them for communication between classes promotes loose coupling.

Well... what about services? In our case, microservices.

One service is loosely coupled from another one when changing it does not require changing the other. You can think about both in terms of behavior or contract.

This is especially important when talking about microservices, because you can have dozens, hundreds, or even thousands of them in your application and if changing one of them requires you to change the others, you could just ruin you entire application.

This recipe will show you how to avoid tight coupling in your microservices, from the first line of code, so you can avoid refactoring in the future (at least for this reason).