Tight coupling means components in a system depend on each other in rigid, time-sensitive ways. When one part fails or lags, the rest cannot adapt; failure propagates quickly and there is little slack to absorb the shock. Loosely coupled systems have buffers, interchangeable parts, and tolerance for delay. Tightly coupled systems run efficiently when everything works and collapse when one link breaks.
Charles Perrow's Normal Accidents (1984) framed it: complex systems with tight coupling and interactive complexity produce failures that are not attributable to a single cause. The more components depend on precise, immediate coordination, the less the system can tolerate variation or error. Manufacturing lines where each station feeds the next with no buffer are tightly coupled. So are just-in-time supply chains, single-threaded software pipelines, and organisations where one person holds critical knowledge.
The strategic question is always: where are we tightly coupled, and what would break if one node failed? Protecting and surviving requires identifying those links, adding redundancy or slack where the cost of failure is high, and accepting that some coupling is unavoidable — in which case you monitor and mitigate.
Section 2
How to See It
Tight coupling reveals itself when a single delay or failure causes disproportionate downstream impact. Look for: no buffers between steps, fixed sequences that cannot be reordered, and critical dependence on one supplier, person, or system. When "we're waiting on X" is a recurring answer, X is a tight-coupling point.
Business
You're seeing Tight Coupling when a production line stops because one machine is down and there is no work-in-progress buffer. Each station depends on the previous one in real time. The failure of one component idles the whole system. The fix is either redundancy at that node or deliberate slack (inventory, parallel paths) to decouple.
Technology
You're seeing Tight Coupling when a microservice or API call is synchronous and blocking: the system cannot proceed until the dependency responds. A single slow or failing dependency cascades to timeouts and user-facing errors. Loose coupling would use queues, caches, or fallbacks so that one failure does not take down the chain.
Investing
You're seeing Tight Coupling when a company's margins depend on one key supplier or one customer. Revenue or cost is tied to a single relationship with no alternative. The thesis is fragile to renegotiation, default, or disruption. The question is whether management has identified and mitigated these single points of failure.
Markets
You're seeing Tight Coupling when a region or sector is dependent on one commodity, one trading partner, or one source of capital. A shock to that single link propagates through the whole system. Diversification and redundancy are the standard responses; the model helps you see where they are missing.
Section 3
How to Use It
Decision filter
"Before relying on a process, supply chain, or architecture, ask: where are we tightly coupled? If one node failed or slowed, would the rest collapse? Where the cost of failure is high, add redundancy, buffers, or alternative paths. Accept tight coupling only where you consciously monitor and mitigate."
As a founder
Map your critical path: product, supply, distribution, key people. Identify the nodes that have no backup and no slack. Those are your tight-coupling points. For each, decide whether to add redundancy (backup supplier, cross-training, fallback tech) or accept the risk and monitor. Startups often run tightly coupled by necessity; the discipline is knowing where and having a plan when a link breaks.
As an investor
Assess how tightly coupled the business is to one customer, one supplier, one channel, or one key person. Tight coupling is a risk factor: it raises the variance of outcomes. The same company can be a good investment if that risk is priced and mitigated, or a bad one if the market assumes stability. Ask how the company would survive the loss of its most critical link.
As a decision-maker
When designing or approving processes, ask where failure would propagate. Tight coupling is sometimes chosen for efficiency; the trade-off is fragility. Where you cannot decouple, invest in monitoring, redundancy at the critical node, or clear contingency plans. The goal is to protect and survive when the inevitable failure occurs.
Common misapplication: Assuming that efficiency and tight coupling always go together. You can often add modest buffers or parallel paths without killing efficiency; the cost of a single catastrophic failure often exceeds the cost of a little slack. Optimise for robustness where the stakes are high.
Second misapplication: Ignoring human and organisational coupling. A process may look decoupled on paper but depend on one person who holds the knowledge or one relationship that cannot be replaced. Map the real dependencies, not just the formal ones.
Grove obsessed over Intel's dependence on a few customers and a few fabs. He pushed for redundant capacity and customer diversification so that no single link could strangle the company. His "only the paranoid survive" was partly about identifying and loosening tight coupling before a crisis exposed it.
Netflix deliberately decoupled content delivery from its own infrastructure by moving to the cloud and designing for redundancy across regions and providers. The goal was to avoid tight coupling to any single data centre or vendor so that local failures would not take down the service.
Section 6
Visual Explanation
Tight Coupling — One failure propagates when there is no buffer or alternative path. Loose coupling adds slack so local failures stay local.
Section 7
Connected Models
Tight coupling sits with bottlenecks, redundancy, and systems thinking. The models below either explain failure propagation, prescribe responses, or frame the system.
Reinforces
[Bottlenecks](/mental-models/bottlenecks)
A bottleneck is a point where flow is constrained. Tight coupling often creates or exacerbates bottlenecks: when the bottleneck fails, the whole chain stops. Find the bottleneck and ask whether it is also a tight-coupling node with no backup.
Reinforces
[Redundancy](/mental-models/redundancy)
Redundancy is the deliberate duplication of critical capacity so that one failure does not take down the system. It is the primary way to loosen tight coupling at a critical node. Redundancy costs more; the trade-off is resilience.
Leads-to
Margin of Safety (Systems)
Margin of safety in systems is the buffer — extra capacity, time, or alternative paths — that allows the system to absorb shocks. It is the design response to tight coupling: add margin where failure would be catastrophic.
Reinforces
Normal Accidents
Normal accidents (Perrow) occur when complex, tightly coupled systems produce failures that are inherent to the design. Tight coupling is one of the two dimensions; the model explains why some systems are accident-prone by structure.
Tension
Section 8
One Key Quote
"Tightly coupled systems have more time-dependent processes, with little slack possible between one step and the next. What happens in one part directly and quickly affects other parts."
— Charles Perrow, Normal Accidents (1984)
Perrow's definition is operational: tight coupling means that steps are time-dependent and that there is little slack. The implication is that failure in one part quickly becomes failure everywhere. The practitioner's job is to map where that is true and then add slack, redundancy, or fail-safes where the cost of failure justifies it.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Tight coupling is the hidden risk in "efficient" systems. Just-in-time supply chains, single-threaded dependencies, and key-person risk are all forms of tight coupling. When everything works, the system is fast and cheap. When one link breaks, the whole chain fails. The discipline is naming the critical links and deciding where to add buffers or backup.
Startups are often tightly coupled by design. Limited resources mean single suppliers, key people, and minimal redundancy. That is acceptable only if you know where the coupling is and have a plan for when it breaks. The mistake is assuming it will not break.
Investors should ask: where is this company tightly coupled? One customer, one supplier, one regulation, one person. The answer determines the variance of outcomes. Companies that have diversified critical dependencies are more robust; those that have not are higher risk, and the price should reflect it.
Decouple where the cost of failure is high. Not every node needs redundancy. The strategic move is to identify the nodes whose failure would be catastrophic and add slack or backup there. Accept tight coupling only where you consciously monitor and mitigate.
Section 10
Summary
Tight coupling means rigid, time-sensitive dependencies between parts of a system; when one fails, the rest cannot adapt and failure spreads. Protecting and surviving requires identifying those links, adding redundancy or slack where failure cost is high, and accepting that some coupling is unavoidable — in which case you monitor and mitigate.
The foundational treatment of tight coupling and interactive complexity. Perrow explains why some systems are prone to normal accidents and how coupling and complexity interact.
Goldratt's theory of constraints illustrates tight coupling in production: the bottleneck is the coupling point. The book shows how to identify and manage it.
Software-focused treatment of resilience. Nygard covers circuit breakers, bulkheads, and timeouts — design patterns that loosen coupling in distributed systems.
Taleb argues that systems that benefit from stress are the opposite of tightly coupled. The book reinforces why redundancy and optionality protect against failure.
Meadows offers a primer on feedback loops, delays, and structure. Useful for mapping where coupling exists and how it affects behaviour.
Systems Thinking
Systems thinking maps how parts interact. Tight coupling is a property of those interactions: strong, rigid dependencies. The tension is that optimising each part for efficiency can increase coupling and make the whole system fragile.
Leads-to
[Fail-safes](/mental-models/fail-safes)
Fail-safes are mechanisms that default to a safe state when something goes wrong. In tightly coupled systems, fail-safes at critical nodes can prevent propagation. Identify coupling, then add redundancy or fail-safes.