What coupling and cohesion are, how tight coupling turns systems into a monolith, and how a loosely coupled ESB architecture makes a business more agile.
Coupling is the degree of interdependence between modules and systems, while cohesion is how well the tasks within a single module fit together. Flexible IT architecture rests on a simple combination: loose coupling between services and strong cohesion within each one. When it is the other way around, systems know too much about each other, any change triggers a chain of edits, and the landscape turns into an IT monolith: expensive to maintain and slow to evolve.
We explain how strong and weak coupling differ, what the enterprise shared context has to do with it, and how to tell a loosely coupled architecture from a monolith.
The ideal is loose coupling between modules and strong cohesion within them: few external dependencies and closely related tasks in one module.
A measure of interdependence between modules. High coupling means modules know too much about each other, making them harder to change and test; that is a sign of a monolith. Low coupling means a change in one module does not require changes in others.
How well aligned the tasks within one module are. High cohesion means the module handles closely related tasks and does not sprawl, which is good. Low cohesion means one module carries mixed responsibilities, making it hard to understand and maintain.
Implementation details are hidden inside the service: it uses only what is exposed by the contract and does not peek inside a neighbor. The fewer assumptions services make about each other (David Parnas's principle), the easier it is to change one part without touching another.
There are two contexts in development: application and enterprise.
An order in CRM and an online store are different entities: in the enterprise context, only the ID, customer, and amount matter; the other CRM attributes are not needed.
With tight coupling, each system must know the other system's internal context to exchange data - contexts get mixed together, integrations turn into point-to-point links, and the landscape becomes a monolith.
With loose coupling, each system acts as if it were the only one in the enterprise and is responsible only for what it contributes to the shared context.
An enterprise service bus (ESB) is the tool that implements this kind of exchange.
A new service is added without affecting the others: they do not know anything was added to the shared context and keep managing their own backlog.
Errors are encapsulated thanks to the small number of links. If one flow fails, the others keep working, and the system handles peak loads.
Understanding dependencies is not limited to an overloaded senior: monitoring is delegated to support, and automatic alerts are set for threshold breaches.
Updating one service does not break the others, and new data flows can be launched quickly, reducing lost opportunity.
Each system is responsible only for its own data in the shared context, without translating requests into a foreign context and causing the losses and errors that come with that.
A service can be replaced or enhanced without rewriting integrations; they can be handed off to any developer or contractor.
For 13 years, KT.Team has been designing loosely coupled integrations for mid-sized and large businesses. A few examples from practice (case studies are in the section cases):
Point-to-point integrations were replaced with lightweight messaging through Kafka - the systems became loosely coupled, and any one of them can be removed or replaced without redesigning the others.
A single message contract and shared API for 200+ 1C systems - a new store is connected by copying a component, with no new development, and integrations have become fault-tolerant and transparent thanks to monitoring.
We designed the target architecture and launched 48 data exchange flows - the new integration map delivered loose coupling and high fault tolerance.
FAQ
Coupling describes the dependency between different modules and systems, while cohesion describes the alignment of tasks within one module. Good architecture means loose coupling between modules and strong cohesion within each one.
Signs of a monolith: a change in one system pulls changes in several others, integrations are built point-to-point, only one overburdened senior can understand the dependencies, and releases are increasingly delayed by cross-team testing.
Fast onboarding of new systems, fault tolerance, simple monitoring, up-to-date data, and protection against vendor lock-in: services change independently without breaking neighbors.
No. Loose coupling can be achieved with an ESB, a message broker, or a modular monolith with clear contracts. What matters is not the microservices trend, but module boundaries and a minimum of assumptions services make about each other.
Start with the integration map and enterprise context: determine which data each system must publish to the shared context. Then replace point-to-point exchange with transfer through a bus or broker, leaving each service responsible only for its own data.
