Keeping Services Loosely Coupled Without Making Everything Abstract

Loose coupling is often praised, but it can become a complex web of interfaces, event buses, and unnecessary layers for simple tasks like sending emails. The author has experience with both tightly coupled and overly abstracted systems, and has found a middle ground. Coupling isn't a binary yes or no question; it depends on what changes together and how often.

Services are tightly coupled if a change in one necessitates coordinated changes in the other. The aim isn't to eliminate coupling altogether, but rather to match the coupling to the rate of change. Services should connect through a stable contract rather than each other's internals. For instance, rather than a consumer knowing the producer's database columns, the producer should expose a contract class.

When the producer adds a new column, the consumer remains unaffected. This sounds straightforward, but many services still reach into each other's tables for faster performance. Prefer asynchronous messages for cross-service operations as synchronous calls can create a chain of failures. If service A calls B, and C, and C goes down, A also goes down.

Async messaging breaks this chain, allowing services to operate independently and not needing to be up simultaneously. Synchronous calls are necessary when an immediate response is required. Contracts and APIs should be versioned from the beginning. Additive changes are safe, but breaking changes need a new version. Never reuse a field as it can lead to silent bugs.

Sharing a database is a major source of hidden coupling. Two services on the same schema cannot be deployed or scaled independently. Extract tables one at a time, creating an API for each, migrating readers, then writers. Although it's slow, it's reversible. Loose coupling isn't a goal to be achieved once and then forgotten. It's a property to be maintained consistently, like performance or readability.