System Design (HLD)Cohesion and Coupling

Cohesion and Coupling

LevelIntermediate

Duration60 mins

TopicCohesion and Coupling

2 / 4

Low Coupling — Minimal Dependencies

The Web of Dependencies

Consider two scenarios facing a development team:

Scenario A: You need to replace the payment gateway. The payment module is isolated—it implements a defined interface, and the rest of the system interacts only through that interface. The switch takes one developer a few days.

Scenario B: You need to replace the payment gateway. Payment logic is woven throughout the codebase—order processing knows about payment details, the reporting system directly queries payment tables, email templates include payment-specific data. The switch takes a team of developers several months, and introduces bugs in unexpected places.

The difference between these scenarios is coupling—the degree to which modules depend on each other. Scenario A has low coupling; Scenario B has high coupling. And that difference translates directly into development velocity, bug frequency, and architectural flexibility.

What You Will Learn

This page examines coupling as the essential complement to cohesion. You will learn to identify different types and levels of coupling, understand why coupling matters for system evolution, and master techniques for achieving the loose coupling that enables independent component development.

Defining Coupling Precisely

Like cohesion, coupling emerged as a formal concept from Constantine and Yourdon's structured design methodology. While cohesion measures how well elements within a module belong together, coupling measures the degree of interdependence between modules.

The formal definition:

Coupling is the degree of interdependence between software modules. A measure of how closely connected two modules are, and how much one module knows about another.

High coupling means modules are tightly interconnected—changes in one require changes in others. Low coupling means modules are relatively independent—changes in one have minimal impact on others.

The key insight is that coupling is about knowledge and dependency. When Module A uses Module B, A becomes dependent on B. The more A knows about B's internals (its data structures, its implementation details, its behavior), the tighter the coupling.

Coupling Is Unavoidable

Unlike cohesion where 'more is better', coupling cannot be eliminated entirely—modules must communicate to form a working system. The goal is to minimize unnecessary coupling and ensure necessary coupling occurs through stable, well-defined interfaces. Zero coupling would mean completely isolated modules that can't work together.

The dimensions of coupling:

Coupling manifests in several dimensions, each affecting system flexibility differently:

Degree — How many other modules does this module depend on?
Strength — How tight is each dependency? (Calling a method vs. accessing internal state)
Direction — Is the dependency one-way or bidirectional? (Bidirectional is worse)
Volatility — How likely is the depended-upon module to change?
Stability — Does the dependency point toward more stable or less stable modules?

A module with few dependencies (low degree), mediated through interfaces (low strength), pointing toward stable abstractions (high stability) has healthy, sustainable coupling.

Why Low Coupling Matters

Low coupling is not an aesthetic goal—it's a pragmatic requirement for building systems that can evolve over time. The benefits are concrete and measurable.

The Strategic Benefits of Low Coupling

•Independent Development — Teams can work on different modules simultaneously without coordination overhead. Low coupling means fewer merge conflicts, fewer integration surprises, and more parallel velocity.
•Localized Changes — When requirements change, the blast radius is contained. Modifying one module doesn't cascade into changes across half the codebase.
•Substitutability — Loosely coupled modules can be replaced with alternative implementations. Swap databases, switch cloud providers, or upgrade frameworks without rewriting dependent code.
•Testability — Modules with few dependencies are easier to test in isolation. You don't need to instantiate an entire system to test one component.
•Understandability — Each module can be understood without understanding everything it connects to. Low coupling reduces the cognitive load of comprehending any single module.
•Resilience — Failures in one module don't necessarily cascade. Low coupling enables graceful degradation, fallbacks, and fault isolation.

The change propagation problem:

High coupling creates change propagation chains—modifications in one module force changes in dependent modules, which force changes in their dependents, and so on. What starts as a simple bug fix becomes a system-wide refactoring exercise.

Consider this example:

Module A depends on Module B's internal data format
Module B changes its data format (for valid reasons)
→ Module A must change to accommodate
→ Module C depends on A's interface, which changed
→ Module C must change
→ Modules D, E, F depend on C...

This cascading effect is why tightly coupled systems become increasingly expensive to maintain. Each change triggers more changes. Eventually, teams become afraid to modify anything because they don't know what will break.

The Coupling Tax

High coupling imposes a compounding tax on every change. The more coupled your system, the more expensive each modification becomes. Over time, this tax can make even simple changes prohibitively expensive, leading to the 'legacy system' phenomenon where the code is too risky to change and too expensive to replace.

The Coupling Spectrum

Constantine and Yourdon identified several levels of coupling, ranging from worst (tightest) to best (loosest). Understanding this spectrum helps you recognize the coupling in your systems and guide improvements.

The levels are presented from tightest (worst) to loosest (best) coupling:

The Coupling Spectrum: From Tightest to Loosest
Level	Description	Example	Quality
Content Coupling	Module directly accesses or modifies another's internal data or code	Module A writes to Module B's private variables	❌ Worst
Common Coupling	Modules share global data	Multiple modules read/write a global configuration object	❌ Poor
External Coupling	Modules share externally imposed data format or protocol	Multiple modules depend on specific file format or API schema	⚠️ Weak
Control Coupling	One module controls another's behavior via parameters	Passing a 'mode' flag that changes what a function does	⚠️ Moderate
Stamp Coupling	Modules share composite data structure but use only parts	Passing entire User object when only userId is needed	✓ Acceptable
Data Coupling	Modules share data through parameters, each uses all passed data	Passing exactly the values needed as primitive parameters	✅ Good
Message Coupling	Communication only via message passing with no shared data	Event-driven systems, message queues, pub/sub	✅ Best

Understanding each level in depth:

Content Coupling (Worst) — One module reaches into another's internals. This might mean directly accessing private fields, modifying internal state, or branching on implementation details. This creates the tightest possible coupling—any change to the internal structure breaks the dependent module. In some languages this is prevented by access modifiers; in others it's merely convention.

Common Coupling — Modules share access to global data. When Module A modifies a global variable that Module B depends on, they're coupled through that shared state. Global state is pernicious because any module can change it, creating unpredictable interactions. The classic symptoms: intermittent bugs, test interference, and initialization order dependencies.

External Coupling — Modules share dependency on an external format or protocol. All modules parsing a specific XML schema are externally coupled—if the schema changes, all must adapt. This coupling is often unavoidable (you must integrate with external systems) but should be isolated behind adapters.

Control Coupling — One module influences another's execution flow through control flags. Passing a boolean isAdmin that changes how a function behaves creates control coupling—the caller must know what modes exist. This often indicates the function does too many things and should be split.

Stamp Coupling — Modules pass complex data structures even when only part is needed. Passing an entire User object when only userId is required means the receiver is coupled to the User structure. If User changes, the receiver might need to change even though it doesn't use the changed parts.

Data Coupling (Good) — The loosest form of call-based coupling. Modules communicate only through parameters, and each parameter is used by the receiver. If a function needs userId, email, and amount, pass exactly those three values. No extraneous data, no control flags, no complex objects.

Message Coupling (Best) — Modules communicate through messages without shared state. In event-driven systems, publishers and subscribers are decoupled—the publisher doesn't know who's listening, and subscribers don't know who published. This enables maximum flexibility and independent evolution.

Practical Target: Aim for Data Coupling

In most systems, message coupling everywhere is impractical. Aim for data coupling as your default—pass exactly the data needed through function parameters. Use message coupling for integration boundaries and asynchronous workflows. Avoid content and common coupling religiously.

Recognizing Coupling in Real Code

Coupling often hides in plain sight. Let's examine concrete examples to develop intuition for spotting problematic dependencies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Module B has internal state
class OrderProcessor {
    _internalState = { retryCount: 0, lastError: null };
    _secretApiKey: string;
    
    processOrder(order: Order) {
        // Processing logic...
    }
}
 
// Module A reaches into B's internals — TIGHT COUPLING
class OrderDashboard {
    private processor = new OrderProcessor();
    
    getProcessorStatus() {
        // Directly accessing internal state!
        if (this.processor._internalState.retryCount > 3) {
            this.displayError(this.processor._internalState.lastError);
        }
        // Even worse: using internal secrets
        this.logApiUsage(this.processor._secretApiKey);
    }
}
 
// Problem: OrderDashboard will break if OrderProcessor's
// internal structure changes in ANY way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Global state that multiple modules use
const globalConfig = {
    dbHost: 'localhost',
    cacheEnabled: true,
    debugMode: false,
    currentUser: null,
    requestCount: 0,
};
 
// Module A modifies global state
class RequestLogger {
    logRequest(req: Request) {
        globalConfig.requestCount++;  // Mutating shared state
        if (globalConfig.debugMode) {
            console.log(req);
        }
    }
}
 
// Module B reads and depends on that state
class MetricsReporter {
    getMetrics() {
        // Depends on Module A having incremented the counter
        return { totalRequests: globalConfig.requestCount };
    }
}
 
// Module C also mutates shared state
class AdminPanel {
    toggleDebug() {
        globalConfig.debugMode = !globalConfig.debugMode;
        // Affects Module A's behavior!
    }
}
 
// Problem: Changes in any module can break any other module.
// Testing requires careful global state management.
// Race conditions in concurrent environments.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// Each function takes exactly what it needs — no more, no less
 
interface OrderData {
    orderId: string;
    amount: number;
    currency: string;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    errorMessage?: string;
}
 
// PaymentProcessor knows nothing about Order internals
class PaymentProcessor {
    async processPayment(
        amount: number,
        currency: string,
        paymentMethodId: string
    ): Promise<PaymentResult> {
        // Only works with the exact data passed
        // No knowledge of orders, users, or other domains
        return this.gateway.charge(amount, currency, paymentMethodId);
    }
}
 
// OrderService uses PaymentProcessor through clean interface
class OrderService {
    constructor(private payments: PaymentProcessor) {}
    
    async fulfillOrder(order: OrderData, paymentMethodId: string) {
        // Passes only what PaymentProcessor needs
        const result = await this.payments.processPayment(
            order.amount,
            order.currency,
            paymentMethodId
        );
        
        if (result.success) {
            await this.markOrderComplete(order.orderId);
        }
        return result;
    }
}
 
// Benefits:
// - PaymentProcessor can be tested without orders
// - OrderService can swap payment processors
// - Changes to Order don't affect PaymentProcessor

Coupling Detection Questions

When reviewing code, ask: (1) How many files would I need to modify to change this? (2) Can I test this without setting up other modules? (3) What happens if this dependency changes internally? (4) Am I passing more data than necessary? Affirmative answers to #1-2 or concerning answers to #3-4 indicate coupling problems.

Techniques for Reducing Coupling

Achieving low coupling requires intentional design decisions and disciplined application of proven techniques. Here are the primary strategies for reducing and maintaining low coupling.

Coupling Reduction Strategies

•Program to interfaces, not implementations — Depend on abstractions (interfaces, abstract classes) rather than concrete implementations. This allows swapping implementations without affecting dependent code. The Dependency Inversion Principle formalizes this.
•Apply the Law of Demeter — 'Only talk to your immediate friends.' Don't reach through objects to access their dependencies. If you find yourself writing a.getB().getC().doSomething(), you're coupling to B and C, not just A.
•Use dependency injection — Pass dependencies in rather than creating them internally. Constructors that instantiate their own dependencies create hidden coupling. Injection makes dependencies explicit and substitutable.
•Minimize public surface area — The more you expose, the more others can depend on. Keep interfaces minimal—expose exactly what clients need and nothing more. Every public method is a potential coupling point.
•Prefer composition over inheritance — Inheritance creates tight coupling to parent classes. Changes to parent affect all children. Composition through interfaces allows flexible assembly without structural coupling.
•Use events for cross-cutting concerns — Instead of direct calls across domains, use event-based communication. Publishers don't know subscribers; subscribers don't know publishers. Maximum decoupling for asynchronous workflows.
•Introduce anti-corruption layers — When integrating with external systems or legacy code, wrap the interface with an adapter that translates to your domain's language. This isolates coupling to the adapter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// ❌ BEFORE: Tight coupling to concrete implementation
class OrderService {
    private emailer = new SmtpEmailService();  // Concrete!
    private db = new PostgresDatabase();        // Concrete!
    
    async createOrder(order: Order) {
        await this.db.insert('orders', order);  // Knows DB details
        await this.emailer.send({               // Knows email details
            to: order.email,
            subject: 'Order Confirmed',
            smtpServer: 'mail.company.com'      // Implementation detail!
        });
    }
}
 
// ✅ AFTER: Loose coupling through interfaces
interface EmailService {
    send(to: string, subject: string, body: string): Promise<void>;
}
 
interface OrderRepository {
    save(order: Order): Promise<void>;
}
 
class OrderService {
    constructor(
        private emailer: EmailService,      // Interface!
        private orders: OrderRepository      // Interface!
    ) {}
    
    async createOrder(order: Order) {
        await this.orders.save(order);       // Abstraction
        await this.emailer.send(             // Abstraction
            order.email,
            'Order Confirmed',
            this.buildConfirmationBody(order)
        );
    }
}
 
// Now OrderService doesn't know about SMTP, Postgres, or any concrete details.
// Can inject MockEmailer for testing, SendGridEmailer for production.

The Interface Segregation Principle

When defining interfaces for decoupling, keep them focused. An interface with 20 methods forces implementers to provide 20 implementations and couples users to all 20. Smaller, focused interfaces (ISP) reduce coupling further.

Coupling in Modern Architectures

Coupling concerns extend beyond code modules into architectural patterns. Microservices, APIs, and distributed systems introduce new coupling dimensions that require specific strategies.

Coupling in Different Architectural Contexts
Context	Common Coupling Points	Mitigation Strategies
Microservices	Service-to-service calls, shared databases, distributed transactions	API contracts, event-driven communication, database-per-service
REST APIs	Client dependence on response structure, URL patterns, versioning	API versioning, hypermedia (HATEOAS), backward compatibility
Message Queues	Message format coupling, queue naming, ordering assumptions	Schema registries, dead letter queues, eventual consistency
Databases	Multiple services querying same tables, stored procedures, triggers	Service-owned data, replication for read models, change data capture
Frontend/Backend	Frontend depending on specific API structure, tight data binding	Backend-for-Frontend (BFF), GraphQL, adapter patterns

The shared database trap:

One of the most common coupling mistakes in distributed systems is the shared database. Multiple services reading from and writing to the same tables creates invisible dependencies:

┌─────────────┐     ┌─────────────────┐     ┌─────────────┐
│   Orders    │────▶│  Shared Orders  │◀────│  Shipping   │
│   Service   │     │     Database    │     │   Service   │
└─────────────┘     └─────────────────┘     └─────────────┘
        │                    ▲                     │
        │                    │                     │
        ▼                    │                     ▼
   Writes order         Both depend on       Reads order,
   record, sets         same schema!         updates status
   initial status

If Orders Service changes the table structure, Shipping Service breaks. You've created a distributed monolith where deployments must be coordinated—losing the independence that microservices promise.

The solution: Each service owns its data. Services communicate via APIs or events, never shared storage. If Shipping needs order data, it either calls Orders Service or maintains its own projection of order events.

API coupling and evolution:

REST APIs create coupling between clients and servers. Every published endpoint, every response field, every URL pattern becomes a dependency. Once clients depend on these, changing them breaks clients.

Strategies for managing API coupling:

Versioning — Support multiple API versions during transitions. /v1/orders and /v2/orders can coexist.
Additive changes only — Add new fields, new endpoints, new optional parameters. Never remove or rename in a breaking way.
Contract testing — Define contracts between services and test both sides against them. Detect breaking changes before deployment.
Consumer-driven contracts — Let clients define what they need; servers verify they provide it. Coupling is explicit and tested.
Tolerant readers — Clients ignore unexpected fields. Servers accept missing optional fields. Both sides tolerate variance.

Distributed Coupling Is Harder to See

In a monolith, coupling is visible in import statements and call graphs. In distributed systems, coupling hides in network calls, message formats, and shared assumptions. You won't see a compiler error when you break a contract—just production failures. Invest in contract testing and API documentation.

Common Coupling Anti-Patterns

Certain design patterns and practices predictably create excessive coupling. Recognizing these anti-patterns helps you avoid them and identify opportunities for decoupling.

Coupling Anti-Patterns to Avoid

•Global State / Singletons everywhere — Every module depending on shared mutable state is coupled to that state and, transitively, to every other module that uses it. Classic symptoms: test pollution, initialization order bugs, hidden dependencies.
•Deep inheritance hierarchies — Each level of inheritance adds coupling to all parent classes. A change at the root ripples to every descendant. Prefer shallow hierarchies and composition.
•God Objects that everyone depends on — A central object that 'knows everything' becomes a coupling magnet. Every module imports and depends on it. Any change risks breaking everything.
•Train wreck calls — Chains like order.getCustomer().getAddress().getCity().toUpperCase(). You're coupled to Order, Customer, Address, City, and String. Follow Law of Demeter.
•Shared data structures across boundaries — Passing the same DTO across service boundaries couples all services to that DTO's schema. Use boundary-specific types instead.
•Hard-coded dependencies — Instantiating dependencies with new ConcreteClass() inside business logic. Use dependency injection to make dependencies explicit and substitutable.
•Temporal coupling — Code that only works if methods are called in a specific order. Callers must know the implicit protocol, creating fragile, order-dependent coupling.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Coupled to entire object graph
function getShippingCity(order: Order) {
  return order
    .getCustomer()
    .getAddress()
    .getCity()
    .toUpperCase();
}
 
// If any intermediate type changes:
// - Customer no longer has getAddress()
// - Address structure changes
// - City becomes a complex type
// This function breaks!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Coupled only to Order
function getShippingCity(order: Order) {
  return order.getShippingCity();
}
 
// Order encapsulates navigation:
class Order {
  getShippingCity(): string {
    return this.customer
      .address
      .city
      .toUpperCase();
  }
}
 
// Internal structure changes don't
// affect external callers.

Coupling Attracts More Coupling

Tightly coupled code tends to attract more coupling. Once modules share internal knowledge, adding more shared knowledge feels natural. Breaking this cycle requires deliberate refactoring to introduce abstractions and enforce boundaries. The longer you wait, the harder it becomes.

Summary: Achieving Low Coupling

We've explored coupling as the measure of interdependence between modules—the complement to cohesion in modular design. Let's consolidate the key insights:

Key Takeaways

•Coupling measures interdependence between modules — High coupling means changes propagate; low coupling means independent evolution.
•Coupling exists on a spectrum from content (worst) to message (best) — Aim for data coupling in most cases; use message coupling at integration boundaries.
•Low coupling enables independent development, testing, and deployment — Teams work faster when they don't need to coordinate on shared code.
•Program to interfaces, not implementations — Abstractions insulate dependents from implementation changes.
•Distributed systems introduce new coupling dimensions — Shared databases, API contracts, and message formats create hidden dependencies that require explicit management.
•Anti-patterns like globals, deep inheritance, and train wrecks create excessive coupling — Recognize and refactor these patterns toward decoupled designs.

What's next:

We've now explored both cohesion and coupling conceptually. The next page examines how to measure cohesion and coupling objectively—moving from intuition to metrics. You'll learn specific measurement techniques and tools that quantify these qualities, enabling data-driven architectural decisions.

Page Complete

You now understand coupling as a critical dimension of modular design. You can identify coupling levels, recognize anti-patterns, and apply techniques for reducing interdependence. Combined with cohesion, you have the conceptual foundation for building well-structured systems.

2 / 4

Loading learning content...

System Design (HLD)Cohesion and Coupling

Cohesion and Coupling

LevelIntermediate

Duration60 mins

TopicCohesion and Coupling

2 / 4

Low Coupling — Minimal Dependencies

The Web of Dependencies

Consider two scenarios facing a development team:

What You Will Learn

Defining Coupling Precisely

The formal definition:

Coupling is the degree of interdependence between software modules. A measure of how closely connected two modules are, and how much one module knows about another.

Coupling Is Unavoidable

The dimensions of coupling:

Coupling manifests in several dimensions, each affecting system flexibility differently:

Degree — How many other modules does this module depend on?
Strength — How tight is each dependency? (Calling a method vs. accessing internal state)
Direction — Is the dependency one-way or bidirectional? (Bidirectional is worse)
Volatility — How likely is the depended-upon module to change?
Stability — Does the dependency point toward more stable or less stable modules?

A module with few dependencies (low degree), mediated through interfaces (low strength), pointing toward stable abstractions (high stability) has healthy, sustainable coupling.

Why Low Coupling Matters

Low coupling is not an aesthetic goal—it's a pragmatic requirement for building systems that can evolve over time. The benefits are concrete and measurable.

The Strategic Benefits of Low Coupling

•Independent Development — Teams can work on different modules simultaneously without coordination overhead. Low coupling means fewer merge conflicts, fewer integration surprises, and more parallel velocity.
•Localized Changes — When requirements change, the blast radius is contained. Modifying one module doesn't cascade into changes across half the codebase.
•Substitutability — Loosely coupled modules can be replaced with alternative implementations. Swap databases, switch cloud providers, or upgrade frameworks without rewriting dependent code.
•Testability — Modules with few dependencies are easier to test in isolation. You don't need to instantiate an entire system to test one component.
•Understandability — Each module can be understood without understanding everything it connects to. Low coupling reduces the cognitive load of comprehending any single module.
•Resilience — Failures in one module don't necessarily cascade. Low coupling enables graceful degradation, fallbacks, and fault isolation.

The change propagation problem:

Consider this example:

Module A depends on Module B's internal data format
Module B changes its data format (for valid reasons)
→ Module A must change to accommodate
→ Module C depends on A's interface, which changed
→ Module C must change
→ Modules D, E, F depend on C...

The Coupling Tax

The Coupling Spectrum

The levels are presented from tightest (worst) to loosest (best) coupling:

The Coupling Spectrum: From Tightest to Loosest
Level	Description	Example	Quality
Content Coupling	Module directly accesses or modifies another's internal data or code	Module A writes to Module B's private variables	❌ Worst
Common Coupling	Modules share global data	Multiple modules read/write a global configuration object	❌ Poor
External Coupling	Modules share externally imposed data format or protocol	Multiple modules depend on specific file format or API schema	⚠️ Weak
Control Coupling	One module controls another's behavior via parameters	Passing a 'mode' flag that changes what a function does	⚠️ Moderate
Stamp Coupling	Modules share composite data structure but use only parts	Passing entire User object when only userId is needed	✓ Acceptable
Data Coupling	Modules share data through parameters, each uses all passed data	Passing exactly the values needed as primitive parameters	✅ Good
Message Coupling	Communication only via message passing with no shared data	Event-driven systems, message queues, pub/sub	✅ Best

Understanding each level in depth:

Practical Target: Aim for Data Coupling

Recognizing Coupling in Real Code

Coupling often hides in plain sight. Let's examine concrete examples to develop intuition for spotting problematic dependencies.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
// Module B has internal state
class OrderProcessor {
    _internalState = { retryCount: 0, lastError: null };
    _secretApiKey: string;
    
    processOrder(order: Order) {
        // Processing logic...
    }
}
 
// Module A reaches into B's internals — TIGHT COUPLING
class OrderDashboard {
    private processor = new OrderProcessor();
    
    getProcessorStatus() {
        // Directly accessing internal state!
        if (this.processor._internalState.retryCount > 3) {
            this.displayError(this.processor._internalState.lastError);
        }
        // Even worse: using internal secrets
        this.logApiUsage(this.processor._secretApiKey);
    }
}
 
// Problem: OrderDashboard will break if OrderProcessor's
// internal structure changes in ANY way.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
// Global state that multiple modules use
const globalConfig = {
    dbHost: 'localhost',
    cacheEnabled: true,
    debugMode: false,
    currentUser: null,
    requestCount: 0,
};
 
// Module A modifies global state
class RequestLogger {
    logRequest(req: Request) {
        globalConfig.requestCount++;  // Mutating shared state
        if (globalConfig.debugMode) {
            console.log(req);
        }
    }
}
 
// Module B reads and depends on that state
class MetricsReporter {
    getMetrics() {
        // Depends on Module A having incremented the counter
        return { totalRequests: globalConfig.requestCount };
    }
}
 
// Module C also mutates shared state
class AdminPanel {
    toggleDebug() {
        globalConfig.debugMode = !globalConfig.debugMode;
        // Affects Module A's behavior!
    }
}
 
// Problem: Changes in any module can break any other module.
// Testing requires careful global state management.
// Race conditions in concurrent environments.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// Each function takes exactly what it needs — no more, no less
 
interface OrderData {
    orderId: string;
    amount: number;
    currency: string;
}
 
interface PaymentResult {
    success: boolean;
    transactionId?: string;
    errorMessage?: string;
}
 
// PaymentProcessor knows nothing about Order internals
class PaymentProcessor {
    async processPayment(
        amount: number,
        currency: string,
        paymentMethodId: string
    ): Promise<PaymentResult> {
        // Only works with the exact data passed
        // No knowledge of orders, users, or other domains
        return this.gateway.charge(amount, currency, paymentMethodId);
    }
}
 
// OrderService uses PaymentProcessor through clean interface
class OrderService {
    constructor(private payments: PaymentProcessor) {}
    
    async fulfillOrder(order: OrderData, paymentMethodId: string) {
        // Passes only what PaymentProcessor needs
        const result = await this.payments.processPayment(
            order.amount,
            order.currency,
            paymentMethodId
        );
        
        if (result.success) {
            await this.markOrderComplete(order.orderId);
        }
        return result;
    }
}
 
// Benefits:
// - PaymentProcessor can be tested without orders
// - OrderService can swap payment processors
// - Changes to Order don't affect PaymentProcessor

Coupling Detection Questions

Techniques for Reducing Coupling

Achieving low coupling requires intentional design decisions and disciplined application of proven techniques. Here are the primary strategies for reducing and maintaining low coupling.

Coupling Reduction Strategies

•Program to interfaces, not implementations — Depend on abstractions (interfaces, abstract classes) rather than concrete implementations. This allows swapping implementations without affecting dependent code. The Dependency Inversion Principle formalizes this.
•Apply the Law of Demeter — 'Only talk to your immediate friends.' Don't reach through objects to access their dependencies. If you find yourself writing a.getB().getC().doSomething(), you're coupling to B and C, not just A.
•Use dependency injection — Pass dependencies in rather than creating them internally. Constructors that instantiate their own dependencies create hidden coupling. Injection makes dependencies explicit and substitutable.
•Minimize public surface area — The more you expose, the more others can depend on. Keep interfaces minimal—expose exactly what clients need and nothing more. Every public method is a potential coupling point.
•Prefer composition over inheritance — Inheritance creates tight coupling to parent classes. Changes to parent affect all children. Composition through interfaces allows flexible assembly without structural coupling.
•Use events for cross-cutting concerns — Instead of direct calls across domains, use event-based communication. Publishers don't know subscribers; subscribers don't know publishers. Maximum decoupling for asynchronous workflows.
•Introduce anti-corruption layers — When integrating with external systems or legacy code, wrap the interface with an adapter that translates to your domain's language. This isolates coupling to the adapter.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
// ❌ BEFORE: Tight coupling to concrete implementation
class OrderService {
    private emailer = new SmtpEmailService();  // Concrete!
    private db = new PostgresDatabase();        // Concrete!
    
    async createOrder(order: Order) {
        await this.db.insert('orders', order);  // Knows DB details
        await this.emailer.send({               // Knows email details
            to: order.email,
            subject: 'Order Confirmed',
            smtpServer: 'mail.company.com'      // Implementation detail!
        });
    }
}
 
// ✅ AFTER: Loose coupling through interfaces
interface EmailService {
    send(to: string, subject: string, body: string): Promise<void>;
}
 
interface OrderRepository {
    save(order: Order): Promise<void>;
}
 
class OrderService {
    constructor(
        private emailer: EmailService,      // Interface!
        private orders: OrderRepository      // Interface!
    ) {}
    
    async createOrder(order: Order) {
        await this.orders.save(order);       // Abstraction
        await this.emailer.send(             // Abstraction
            order.email,
            'Order Confirmed',
            this.buildConfirmationBody(order)
        );
    }
}
 
// Now OrderService doesn't know about SMTP, Postgres, or any concrete details.
// Can inject MockEmailer for testing, SendGridEmailer for production.

The Interface Segregation Principle

Coupling in Modern Architectures

Coupling concerns extend beyond code modules into architectural patterns. Microservices, APIs, and distributed systems introduce new coupling dimensions that require specific strategies.

Coupling in Different Architectural Contexts
Context	Common Coupling Points	Mitigation Strategies
Microservices	Service-to-service calls, shared databases, distributed transactions	API contracts, event-driven communication, database-per-service
REST APIs	Client dependence on response structure, URL patterns, versioning	API versioning, hypermedia (HATEOAS), backward compatibility
Message Queues	Message format coupling, queue naming, ordering assumptions	Schema registries, dead letter queues, eventual consistency
Databases	Multiple services querying same tables, stored procedures, triggers	Service-owned data, replication for read models, change data capture
Frontend/Backend	Frontend depending on specific API structure, tight data binding	Backend-for-Frontend (BFF), GraphQL, adapter patterns

The shared database trap:

One of the most common coupling mistakes in distributed systems is the shared database. Multiple services reading from and writing to the same tables creates invisible dependencies:

┌─────────────┐     ┌─────────────────┐     ┌─────────────┐
│   Orders    │────▶│  Shared Orders  │◀────│  Shipping   │
│   Service   │     │     Database    │     │   Service   │
└─────────────┘     └─────────────────┘     └─────────────┘
        │                    ▲                     │
        │                    │                     │
        ▼                    │                     ▼
   Writes order         Both depend on       Reads order,
   record, sets         same schema!         updates status
   initial status

API coupling and evolution:

Strategies for managing API coupling:

Versioning — Support multiple API versions during transitions. /v1/orders and /v2/orders can coexist.
Additive changes only — Add new fields, new endpoints, new optional parameters. Never remove or rename in a breaking way.
Contract testing — Define contracts between services and test both sides against them. Detect breaking changes before deployment.
Consumer-driven contracts — Let clients define what they need; servers verify they provide it. Coupling is explicit and tested.
Tolerant readers — Clients ignore unexpected fields. Servers accept missing optional fields. Both sides tolerate variance.

Distributed Coupling Is Harder to See

Common Coupling Anti-Patterns

Certain design patterns and practices predictably create excessive coupling. Recognizing these anti-patterns helps you avoid them and identify opportunities for decoupling.

Coupling Anti-Patterns to Avoid

•Global State / Singletons everywhere — Every module depending on shared mutable state is coupled to that state and, transitively, to every other module that uses it. Classic symptoms: test pollution, initialization order bugs, hidden dependencies.
•Deep inheritance hierarchies — Each level of inheritance adds coupling to all parent classes. A change at the root ripples to every descendant. Prefer shallow hierarchies and composition.
•God Objects that everyone depends on — A central object that 'knows everything' becomes a coupling magnet. Every module imports and depends on it. Any change risks breaking everything.
•Train wreck calls — Chains like order.getCustomer().getAddress().getCity().toUpperCase(). You're coupled to Order, Customer, Address, City, and String. Follow Law of Demeter.
•Shared data structures across boundaries — Passing the same DTO across service boundaries couples all services to that DTO's schema. Use boundary-specific types instead.
•Hard-coded dependencies — Instantiating dependencies with new ConcreteClass() inside business logic. Use dependency injection to make dependencies explicit and substitutable.
•Temporal coupling — Code that only works if methods are called in a specific order. Callers must know the implicit protocol, creating fragile, order-dependent coupling.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Coupled to entire object graph
function getShippingCity(order: Order) {
  return order
    .getCustomer()
    .getAddress()
    .getCity()
    .toUpperCase();
}
 
// If any intermediate type changes:
// - Customer no longer has getAddress()
// - Address structure changes
// - City becomes a complex type
// This function breaks!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Coupled only to Order
function getShippingCity(order: Order) {
  return order.getShippingCity();
}
 
// Order encapsulates navigation:
class Order {
  getShippingCity(): string {
    return this.customer
      .address
      .city
      .toUpperCase();
  }
}
 
// Internal structure changes don't
// affect external callers.

Coupling Attracts More Coupling

Summary: Achieving Low Coupling

We've explored coupling as the measure of interdependence between modules—the complement to cohesion in modular design. Let's consolidate the key insights:

Key Takeaways

•Coupling measures interdependence between modules — High coupling means changes propagate; low coupling means independent evolution.
•Coupling exists on a spectrum from content (worst) to message (best) — Aim for data coupling in most cases; use message coupling at integration boundaries.
•Low coupling enables independent development, testing, and deployment — Teams work faster when they don't need to coordinate on shared code.
•Program to interfaces, not implementations — Abstractions insulate dependents from implementation changes.
•Distributed systems introduce new coupling dimensions — Shared databases, API contracts, and message formats create hidden dependencies that require explicit management.
•Anti-patterns like globals, deep inheritance, and train wrecks create excessive coupling — Recognize and refactor these patterns toward decoupled designs.

What's next:

Page Complete

2 / 4