Loose Coupling Basics

Loose Couple Your App

Having a loosely coupled app is a good scalability practice.

So what is coupling?

Coupling is a measure of how two or more components depend on each other. If one of your components stops working if the other component is down, then they are tightly coupled. Retrospectively, the less those components depend on each other, the more they are loosely coupled. Ideally you want your components to be 100% independent.

Suppose that you have a BookCatalogue service that is tightly coupled with 2 other services: BookLenders and BookDistributors. If one day you deprecate one of the BookCatalogue's APIs, there is a good chance that it will also break BookLenders and BookDistributors because they depend on each other, causing funky bugs! However, if your services were loosely coupled, then deprecating one would not break others.

When you have fully autonomous services, you can freely change one service without worrying that other service will break. In reality, it is nigh impossible to make all your services to be fully independent. Your goal is to write most of them to be as self-reliant as possible, as much as you can.

One way to help this is before coding your service, draw a distinct boundary what each service is supposed to do and stick to it. Each service should have a separate responsibility. The clearer the boundary, the easier it is to separate them.

Advantages of loose coupling

There are several advantages of having loosely coupled services:

• First, it is easier to scale loosely coupled services than tightly coupled ones. If you assign a dedicated server for each service you can easily scale up or down only the server of that particular service.

• Second, it is easier to assign a team to a particular service if it is loosely coupled. Pushing changes should not break the others. The teams can work with great autonomy. This lets your organization to work in parallel so you can get more done with less time!

• Third, it easier to understand the loosely coupled services from a high level perspective. It is easy to see that the BookLenders service is responsible for handling the book lending process and BookCatalogue is responsible for book listings. Contrast that if you only have one service, BookLibrary, that handles both book listing and lenders. It is harder to draw the line in your head what exactly is the responsibility of this service.

You can apply loose coupling methodology at any level in your system. You can have loosely coupled application layers, modules, and even classes. The idea is one and the same: make each component as autonomous as possible and assign each a sole responsibility.