In computing and systems design, a loosely coupled system is one
in which components are weakly associated (have breakable relationships) with each other, and thus changes in one component least affect existence or performance of another component.
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.
Components in a loosely coupled system can be replaced with alternative implementations that provide the same services. Components in a loosely coupled system are less constrained to the same platform, language, operating system, or build environment.
If systems are decoupled in time, it is difficult to also provide transactional integrity; additional coordination protocols are required. Data replication across different systems provides loose coupling (in availability), but creates issues in maintaining consistency (data synchronization).
Loose coupling in broader distributed system design is achieved by the use of transactions, queues provided by message-oriented middleware, and interoperability standards.
Four types of autonomy, which promote loose coupling, are: reference autonomy, time autonomy, format autonomy, and platform autonomy.
Loose coupling is an architectural principle and design goal in service-oriented architectures; eleven forms of loose coupling and their tight coupling counterparts are listed in:
physical connections via mediator,
asynchronous communication style,
simple common types only in data model,
weak type system,
data-centric and self-contained messages,
distributed control of process logic,
dynamic binding (of service consumers and providers),
platform independence,
business-level compensation rather than system-level transactions,
deployment at different times,
implicit upgrades in versioning.