System Design (LLD)Publish-Subscribe Pattern

Publish-Subscribe Pattern

LevelIntermediate

Duration90 mins

TopicPublish-Subscribe Pattern

3 / 4

Coupling and Decoupling

The True Benefit: Freedom to Change

We've discussed how publishers and subscribers don't know about each other, mediated by an event bus. But why does this mutual ignorance matter? Why do architects prize decoupling so highly?

The answer is deceptively profound: decoupling provides freedom to change. When components are tightly coupled, changing one forces changes in others—a cascade that makes systems rigid, fragile, and expensive to evolve. Decoupling breaks these chains, allowing each component to evolve independently.

This page explores coupling and decoupling deeply: what they mean, how to measure them, how pub-sub achieves decoupling, and the trade-offs involved.

What You Will Learn

By the end of this page, you will understand the different types of coupling, how to recognize them in code, how the publish-subscribe pattern achieves decoupling, and the trade-offs you accept when choosing decoupled designs.

Understanding Coupling

Coupling measures the degree to which one module depends on another. High coupling means changes in one module frequently require changes in another. Low coupling means modules can evolve independently.

Types of Coupling (Ordered by Severity)

Coupling exists on a spectrum from tight (harmful) to loose (desirable):

Types of Coupling (Most Harmful → Least Harmful)
Type	Description	Example	Severity
Content Coupling	One module directly modifies another's internal data	Accessing private fields via reflection	🔴 Severe
Common Coupling	Modules share global data	Multiple services modifying shared database table	🔴 Severe
Control Coupling	One module controls another's behavior via flags	`process(data, includeDetails=true, format='json')`	🟠 Moderate
Stamp Coupling	Modules share data structures but use only parts	Passing entire User object when only ID is needed	🟠 Moderate
Data Coupling	Modules share only necessary data via parameters	`sendEmail(email, subject, body)`	🟢 Acceptable
Message Coupling	Modules communicate via messages without direct reference	Publish-Subscribe pattern	🟢 Ideal

Coupling in Direct Method Calls

The most common form of coupling in object-oriented systems is direct method coupling—one class calls methods on another. This creates several dependencies:

direct-coupling-example.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
/**
 * Tightly Coupled Order Processing
 * 
 * OrderService has DIRECT dependencies on every downstream service.
 * This creates multiple types of coupling.
 */
class TightlyCoupledOrderService {
    constructor(
        // Direct dependency on each service
        private readonly emailService: EmailService,
        private readonly inventoryService: InventoryService,
        private readonly analyticsService: AnalyticsService,
        private readonly warehouseService: WarehouseService,
        private readonly fraudService: FraudDetectionService,
        private readonly loyaltyService: LoyaltyPointsService
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // COUPLING: Must know all services
        // COUPLING: Must know their method signatures
        // COUPLING: Must know the order of operations
        // COUPLING: Must handle each service's errors
        
        await this.emailService.sendOrderConfirmation(order);
        await this.inventoryService.reserveItems(order.items);
        await this.analyticsService.trackPurchase(order);
        await this.warehouseService.createPickList(order);
        await this.fraudService.analyze(order);
        await this.loyaltyService.awardPoints(order.customerId, order.totalAmount);
        
        return order;
    }
}
 
/**
 * Problems with this coupling:
 * 
 * 1. KNOWLEDGE: OrderService must know about 6 other services
 * 
 * 2. CHANGES: Adding a new reaction (e.g., SMS notification) requires:
 *    - Adding new constructor parameter
 *    - Adding new method call
 *    - Modifying OrderService code
 *    - Redeploying OrderService
 * 
 * 3. TESTING: Must mock 6 dependencies for unit tests
 * 
 * 4. FAILURES: If emailService is down:
 *    - Does the entire operation fail?
 *    - Does it continue with partial success?
 *    - OrderService must contain this logic
 * 
 * 5. PERFORMANCE: All operations are serial (can parallelize, but OrderService
 *    must manage the complexity)
 * 
 * 6. ORDERING: What if warehouseService needs inventory reserved first?
 *    OrderService must encode this business logic
 */

Coupling Grows Over Time

Tightly coupled systems start simple but grow unwieldy. That first emailService.send(order) seems harmless. By the time you have 20 downstream services, the OrderService has become a coordination nightmare that nobody wants to modify.

The Cost of Coupling

Coupling imposes concrete costs that compound over time. Understanding these costs motivates the effort required to achieve decoupling.

The Ripple Effect

In coupled systems, changes propagate like ripples in a pond. A small change in one component forces changes in others, which force changes in others, and so on.

ripple-effect.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * The Ripple Effect of Coupling
 * 
 * Scenario: The EmailService team decides to add rate limiting.
 * They change the method signature:
 * 
 * BEFORE: sendEmail(to: string, subject: string, body: string)
 * AFTER:  sendEmail(to: string, subject: string, body: string, options?: EmailOptions)
 * 
 * This is a COMPATIBLE change. But watch the ripple...
 */
 
// Version 1: Original EmailService
class EmailServiceV1 {
    async sendEmail(to: string, subject: string, body: string): Promise<void> {
        await this.transport.send({ to, subject, body });
    }
}
 
// Version 2: Added priority support
class EmailServiceV2 {
    async sendEmail(
        to: string,
        subject: string,
        body: string,
        options?: { priority?: 'high' | 'normal' | 'low' }
    ): Promise<void> {
        await this.transport.send({ to, subject, body, ...options });
    }
}
 
// Now OrderService wants to send high-priority emails for large orders
class OrderServiceUpdated {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Need to know about EmailService's new options structure
        const priority = order.totalAmount > 1000 ? 'high' : 'normal';
        
        await this.emailService.sendEmail(
            order.customerEmail,
            'Order Confirmation',
            this.generateBody(order),
            { priority }  // Must know EmailService's interface details
        );
        
        return order;
    }
}
 
/**
 * The "small" EmailService change cascaded to:
 * 
 * 1. OrderService needs updating (to use priority feature)
 * 2. ShipmentService needs updating (track shipping emails need high priority)
 * 3. ReturnService needs updating
 * 4. PasswordResetService needs updating
 * 5. MarketingService needs updating (promotions are low priority)
 * 
 * Each service must:
 * - Know about the new options structure
 * - Decide what priority to use
 * - Update their integration tests
 * - Coordinate deployment timing
 * 
 * A "simple" additive change becomes 6 deployments.
 */

Business Costs of Coupling

•Slower Delivery — Changes require coordinated updates across multiple teams and services. What should be a 1-day fix becomes a 2-week project.
•Higher Risk — Each change touches more code, increasing the chance of bugs. Deployments become scary because the blast radius is large.
•Reduced Agility — Business requests like 'add SMS notifications' become major undertakings instead of simple additions.
•Testing Complexity — Testing one component requires setting up or mocking many others. Test suites become slow and brittle.
•Team Dependencies — Team A can't ship until Team B updates their service. Calendar tetris replaces independent progress.
•Knowledge Silos — Developers must understand the entire dependency graph to make safe changes, limiting who can contribute.

Conway's Law in Action

Coupling in code often mirrors coupling in organizations. Teams that must coordinate constantly produce tightly coupled systems. The reverse is also true: decoupled architectures enable autonomous teams.

How Pub-Sub Achieves Decoupling

The Publish-Subscribe pattern achieves decoupling through indirection and inversion of dependency. Let's see how this works.

Before: Direct Dependencies

before-pubsub.ts
TypeScript
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
/**
 * BEFORE: Direct Dependencies
 * 
 * OrderService => EmailService
 * OrderService => InventoryService
 * OrderService => AnalyticsService
 * 
 * Changes flow FROM OrderService TO each dependency.
 * Adding new reactions requires modifying OrderService.
 */
class OrderService {
    constructor(
        private readonly emailService: EmailService,
        private readonly inventoryService: InventoryService,
        private readonly analyticsService: AnalyticsService
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Direct calls create coupling
        await this.emailService.sendOrderConfirmation(order);
        await this.inventoryService.reserveItems(order.items);
        await this.analyticsService.trackPurchase(order);
        
        return order;
    }
}
 
/**
 * Dependency Graph:
 * 
 *                    ┌─────────────┐
 *                    │ OrderService │
 *                    └──────┬──────┘
 *                           │
 *          ┌────────────────┼────────────────┐
 *          ▼                ▼                ▼
 *   ┌────────────┐  ┌────────────────┐  ┌──────────────┐
 *   │EmailService│  │InventoryService│  │AnalyticsService│
 *   └────────────┘  └────────────────┘  └──────────────┘
 * 
 * OrderService KNOWS about all three services.
 * Adding a 4th service requires modifying OrderService.
 */

After: Event-Based Decoupling

after-pubsub.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
/**
 * AFTER: Event-Based Decoupling
 * 
 * OrderService => EventBus (publishes OrderPlaced)
 * EmailSubscriber <= EventBus (listens for OrderPlaced)
 * InventorySubscriber <= EventBus (listens for OrderPlaced)
 * AnalyticsSubscriber <= EventBus (listens for OrderPlaced)
 * 
 * OrderService knows NOTHING about subscribers.
 * Subscribers know NOTHING about OrderService.
 * Both know only about the event contract.
 */
class OrderService {
    constructor(
        private readonly eventBus: IEventBus  // Only dependency: the bus
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Publish event - doesn't know who listens
        await this.eventBus.publish({
            eventType: 'OrderPlaced',
            eventId: generateUUID(),
            occurredAt: new Date(),
            aggregateId: order.id,
            payload: {
                orderId: order.id,
                customerId: order.customerId,
                items: order.items,
                totalAmount: order.totalAmount,
                customerEmail: order.customerEmail
            }
        });
        
        return order;
    }
}
 
// Subscribers register themselves - OrderService doesn't know about them
class EmailSubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.sendConfirmationEmail(event.payload);
    }
}
 
class InventorySubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.reserveInventory(event.payload.items);
    }
}
 
class AnalyticsSubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.trackPurchase(event.payload);
    }
}
 
/**
 * New Dependency Graph:
 * 
 *   ┌─────────────┐                          ┌────────────────────┐
 *   │ OrderService │ ──publishes──►          │                    │
 *   └─────────────┘               ▼          │                    │
 *                           ┌───────────┐    │   ┌──────────────┐ │
 *                           │ EventBus  │◄───┼───│EmailSubscriber│ │
 *                           │           │    │   └──────────────┘ │
 *                           │OrderPlaced│◄───┼───│InventorySub  │ │
 *                           │  Event    │    │   └──────────────┘ │
 *                           │           │◄───┼───│AnalyticsSub  │ │
 *                           └───────────┘    │   └──────────────┘ │
 *                                            │                    │
 *                                            └─ Subscribers self-register
 * 
 * OrderService knows ONLY about EventBus.
 * Adding a 4th subscriber requires ZERO changes to OrderService.
 * Each subscriber can be developed, tested, deployed independently.
 */

What Pub-Sub Decouples

•Identity Decoupling — Publishers don't know subscriber identities. Subscribers don't know publisher identities.
•Location Decoupling — Publishers and subscribers can be in the same process, different processes, or different machines.
•Time Decoupling — With persistent message queues, publishers and subscribers don't need to be running simultaneously.
•Cardinality Decoupling — One event can trigger zero, one, or many reactions. The publisher doesn't care.
•Interface Decoupling — Subscribers don't call publisher methods. They react to the event contract, not the publisher's API.

Measuring Coupling Reduction

Let's quantify how pub-sub reduces coupling with concrete metrics.

Afferent and Efferent Coupling

Afferent Coupling (Ca): Number of modules that depend ON this module
Efferent Coupling (Ce): Number of modules this module depends ON

Instability (I) = Ce / (Ca + Ce)

I = 0: Fully stable (everyone depends on it, changes are costly)
I = 1: Fully unstable (depends on everyone, easy to change)

Coupling Metrics: Before vs After Pub-Sub
Metric	OrderService (Before)	OrderService (After)	Change
Efferent Coupling (Ce)	6 (knows 6 services)	1 (knows only EventBus)	🟢 -5 dependencies
Lines to modify to add service	~10 (new constructor param, method call)	0	🟢 Zero changes
Import statements	6 (one per service)	1 (IEventBus)	🟢 -5 imports
Constructor parameters	6	1	🟢 -5 parameters
Test mocks required	6	1	🟢 -5 mocks

Change Impact Analysis

Consider the impact of a common change: adding SMS notifications for orders.

Direct Coupling

•
1. Create SMSService class
•
1. Add constructor parameter to OrderService
•
1. Add method call to OrderService.placeOrder()
•
1. Update OrderService tests
•
1. Update OrderService deployment
•
1. Coordinate release with Order team
•Files changed: 4+
•Teams involved: 2
•Risk: Moderate (OrderService changes)

Pub-Sub Decoupling

•
1. Create SMSSubscriber class
•
1. Register with event bus
•
1. Done
•
•
•
•Files changed: 1-2
•Teams involved: 1
•Risk: Low (OrderService unchanged)

The Open-Closed Principle in Action

Pub-Sub embodies the Open-Closed Principle: the system is OPEN for extension (new subscribers) but CLOSED for modification (existing code unchanged). You extend behavior by adding, not by editing.

Types of Decoupling in Pub-Sub

The Publish-Subscribe pattern provides three distinct forms of decoupling. Understanding each helps you leverage them appropriately.

1. Space Decoupling (Location Independence)

Publishers and subscribers don't need to know each other's locations. They could be:

In the same process (in-memory event bus)
Different processes on the same machine
Different machines in the same data center
Geographically distributed across the globe

The only requirement is connectivity to the event bus/broker.

space-decoupling.ts
TypeScript
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
/**
 * Space Decoupling: Location Independence
 * 
 * These components work regardless of where they're deployed.
 */
 
// Publisher: Could run anywhere
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Publishes to event bus - doesn't care where it goes
        await this.eventBus.publish(createOrderPlacedEvent(order));
        
        return order;
    }
}
 
// Subscriber: Could run anywhere
class EmailNotificationSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Processes event - doesn't care where it came from
        await this.sendEmail(event.payload.customerEmail);
    }
}
 
/**
 * Deployment Possibilities:
 * 
 * Scenario 1: Monolith
 *   [Process 1]
 *   ├── OrderService (publisher)
 *   ├── InMemoryEventBus
 *   └── EmailSubscriber
 * 
 * Scenario 2: Microservices, Same Region
 *   [Order Service Container] ──► [Kafka Cluster] ──► [Email Service Container]
 * 
 * Scenario 3: Global Distribution
 *   [US-East: Order Service] ──► [Global Kafka] ──► [EU-West: Email Service]
 * 
 * The code doesn't change. Only infrastructure configuration.
 */

2. Time Decoupling (Temporal Independence)

With durable message queues, publishers and subscribers don't need to be running simultaneously. Events persist until consumed.

time-decoupling.ts
TypeScript
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
/**
 * Time Decoupling: Temporal Independence
 * 
 * With durable event storage, timing doesn't matter.
 */
 
// Scenario: Publisher runs but subscriber is down
async function handleOrderDuringSubscriberDowntime() {
    // 10:00 AM: OrderService publishes
    await orderService.placeOrder(command);
    // Event is stored in Kafka/RabbitMQ
    
    // 10:00 AM - 11:00 AM: EmailService is down for maintenance
    // Events queue up in the broker
    
    // 11:00 AM: EmailService comes back online
    // Broker delivers queued events
    // Customer receives email an hour late, but receives it
}
 
// Benefits:
// 1. Maintenance windows don't cause data loss
// 2. Subscriber can process at its own pace
// 3. Traffic spikes are absorbed by the queue
// 4. Subscribers can "catch up" after downtime
 
// Configuration for time decoupling (Kafka example)
const kafkaConfig = {
    // Events retained for 7 days
    'log.retention.hours': 168,
    
    // Subscribers can rewind and replay
    'auto.offset.reset': 'earliest',
};
 
// Configuration for time decoupling (RabbitMQ example)
const rabbitQueue = {
    // Queue survives broker restart
    durable: true,
    
    // Messages survive broker restart
    persistent: true,
    
    // Keep up to 1M messages or 1GB
    maxLength: 1000000,
    maxLengthBytes: 1073741824
};

3. Synchronization Decoupling (Flow Independence)

Publishers don't block waiting for subscribers. Each subscriber processes at its own pace.

sync-decoupling.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
/**
 * Synchronization Decoupling: Flow Independence
 * 
 * Publisher completes immediately. Subscribers proceed independently.
 */
 
// Publisher: Returns quickly
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // This returns immediately after message is queued
        // Publisher doesn't wait for ANY subscriber to finish
        await this.eventBus.publish(createOrderPlacedEvent(order));
        
        // Response returned to user: ~50ms
        return order;
    }
}
 
// Fast subscriber: Processes in 100ms
class AnalyticsSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Quick fire-and-forget to analytics service
        await this.analytics.track(event.payload);
    }
}
 
// Slow subscriber: Processes in 5 seconds
class ReportGenerationSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Complex PDF generation, database aggregations
        await this.generateOrderReport(event.payload);
        await this.storeInArchive(event.payload);
    }
}
 
// Very slow subscriber: Processes in 30 seconds
class ExternalSystemSyncSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Slow external API with rate limiting
        await this.syncToLegacyERP(event.payload);
        await this.syncToExternalCRM(event.payload);
    }
}
 
/**
 * Flow Analysis:
 * 
 * Without Pub-Sub (synchronous calls):
 *   User waits: 50ms + 100ms + 5000ms + 30000ms = 35.15 seconds
 *   Terrible UX. API timeout likely.
 * 
 * With Pub-Sub:
 *   User waits: 50ms (just order creation + publish)
 *   Subscribers process in parallel in background
 *   User gets immediate response
 * 
 * The slow subscriber doesn't slow down:
 *   - The publisher
 *   - Other subscribers
 *   - The user experience
 */

Trade-offs of Decoupling

Decoupling isn't free. It introduces trade-offs that you must understand and manage. Being honest about these trade-offs leads to better architectural decisions.

Complexity Trade-offs

Decoupling Trade-offs
Benefit	Trade-off	Mitigation
Independence from subscriber failures	Harder to know if processing succeeded	Dead letter queues, monitoring, alerts
Easy to add new reactions	Harder to see what happens when event fires	Event documentation, tracing tools
Asynchronous processing	Eventual consistency (not immediate)	Design for eventual consistency explicitly
No direct method coupling	Must maintain event contracts carefully	Event versioning, schema registry
Location independence	Network failures, latency concerns	Retries, idempotency, timeout handling

The Debuggability Challenge

In a directly coupled system, you can trace execution through a single call stack. In an event-driven system, the flow is distributed and harder to follow.

debuggability-challenge.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Debuggability Challenge
 * 
 * In coupled code, you can trace the full flow:
 */
 
// Coupled: Easy to trace (but hard to change)
async function placeOrderCoupled(command: PlaceOrderCommand) {
    const order = await createOrder(command);          // Line 1
    await emailService.send(order);                    // Line 2
    await inventoryService.reserve(order);             // Line 3
    await analyticsService.track(order);               // Line 4
    return order;                                      // Line 5
}
// Stack trace shows exactly where it failed: line 3, inventoryService
 
// Event-driven: Harder to trace (but easier to change)
async function placeOrderEventDriven(command: PlaceOrderCommand) {
    const order = await createOrder(command);          // Line 1
    await eventBus.publish(orderPlacedEvent);          // Line 2
    return order;                                      // Line 3
}
// Stack trace stops at line 2
// What happened after? Which subscribers ran? Which failed?
// Need distributed tracing to see full picture
 
/**
 * Mitigation: Correlation IDs and Distributed Tracing
 */
interface TraceableEvent extends DomainEvent {
    readonly correlationId: string;  // Links all related events
    readonly causationId: string;    // What caused this event
    readonly traceId: string;        // Spans entire request lifecycle
}
 
// All subscribers propagate tracing context
class TracedEmailSubscriber implements ISubscriber<TraceableEvent> {
    async handle(event: TraceableEvent): Promise<void> {
        // Create child span linked to parent trace
        const span = tracer.startSpan('email.send', {
            childOf: event.traceId,
            tags: {
                'event.id': event.eventId,
                'event.type': event.eventType,
                'correlation.id': event.correlationId
            }
        });
        
        try {
            await this.sendEmail(event.payload);
            span.setStatus('ok');
        } catch (error) {
            span.setStatus('error');
            span.log({ error: error.message });
            throw error;
        } finally {
            span.finish();
        }
    }
}
 
// Now tracing tools (Jaeger, Zipkin, Datadog) show:
// [OrderService.placeOrder] 50ms
//   └── [EventBus.publish] 5ms
//       ├── [EmailSubscriber.handle] 200ms ✓
//       ├── [InventorySubscriber.handle] 150ms ✗ (error)
//       └── [AnalyticsSubscriber.handle] 30ms ✓

Invest in Observability

Event-driven systems require stronger observability. Budget for distributed tracing, event logging, and monitoring dashboards. The debugging difficulty is real, but it's solvable with proper tooling.

When NOT to Decouple

Decoupling isn't always the right choice. Some scenarios call for direct coupling:

Keep Direct Coupling When

•Immediate consistency is required — Payment must be confirmed before order confirmation. Don't use eventual consistency for critical paths.
•Order of operations matters and is complex — If step B must happen exactly after step A, direct calls make this explicit.
•The relationship is truly one-to-one — If only one thing ever reacts to an event, the indirection may not be worth it.
•Debugging simplicity is paramount — Early-stage startups may prefer debuggability over extensibility.
•The domain is well-understood and stable — If you're confident about the behavior and it won't change, coupling is simpler.

Summary: Coupling and Decoupling

Understanding coupling and decoupling is essential for making good architectural decisions. The Publish-Subscribe pattern is a powerful tool for achieving decoupling, but it's not appropriate for every situation.

Key Takeaways

•Coupling measures dependency — High coupling means changes cascade across the system.
•Direct coupling has real costs — Slower delivery, higher risk, reduced agility, complex testing.
•Pub-Sub achieves decoupling through indirection — Publishers and subscribers know only the event contract, not each other.
•Three types of decoupling — Space (location), time (temporal), and synchronization (flow).
•Decoupling has trade-offs — Eventual consistency, debugging complexity, infrastructure needs.
•Measure coupling reduction — Use metrics like efferent coupling and change impact analysis.
•Don't decouple everything — Direct coupling is appropriate when consistency, ordering, or simplicity are critical.

What's next:

With the theory of pub-sub and decoupling understood, we'll explore practical implementation approaches: how to build event buses, choose message brokers, and structure event-driven code in real applications.

Page Complete

You now understand why decoupling matters and how the Publish-Subscribe pattern achieves it. You can recognize coupling in code, measure its reduction, and make informed decisions about when decoupling is worth the trade-offs.

3 / 4

Loading learning content...

System Design (LLD)Publish-Subscribe Pattern

Publish-Subscribe Pattern

LevelIntermediate

Duration90 mins

TopicPublish-Subscribe Pattern

3 / 4

Coupling and Decoupling

The True Benefit: Freedom to Change

We've discussed how publishers and subscribers don't know about each other, mediated by an event bus. But why does this mutual ignorance matter? Why do architects prize decoupling so highly?

This page explores coupling and decoupling deeply: what they mean, how to measure them, how pub-sub achieves decoupling, and the trade-offs involved.

What You Will Learn

Understanding Coupling

Types of Coupling (Ordered by Severity)

Coupling exists on a spectrum from tight (harmful) to loose (desirable):

Types of Coupling (Most Harmful → Least Harmful)
Type	Description	Example	Severity
Content Coupling	One module directly modifies another's internal data	Accessing private fields via reflection	🔴 Severe
Common Coupling	Modules share global data	Multiple services modifying shared database table	🔴 Severe
Control Coupling	One module controls another's behavior via flags	`process(data, includeDetails=true, format='json')`	🟠 Moderate
Stamp Coupling	Modules share data structures but use only parts	Passing entire User object when only ID is needed	🟠 Moderate
Data Coupling	Modules share only necessary data via parameters	`sendEmail(email, subject, body)`	🟢 Acceptable
Message Coupling	Modules communicate via messages without direct reference	Publish-Subscribe pattern	🟢 Ideal

Coupling in Direct Method Calls

The most common form of coupling in object-oriented systems is direct method coupling—one class calls methods on another. This creates several dependencies:

direct-coupling-example.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
/**
 * Tightly Coupled Order Processing
 * 
 * OrderService has DIRECT dependencies on every downstream service.
 * This creates multiple types of coupling.
 */
class TightlyCoupledOrderService {
    constructor(
        // Direct dependency on each service
        private readonly emailService: EmailService,
        private readonly inventoryService: InventoryService,
        private readonly analyticsService: AnalyticsService,
        private readonly warehouseService: WarehouseService,
        private readonly fraudService: FraudDetectionService,
        private readonly loyaltyService: LoyaltyPointsService
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // COUPLING: Must know all services
        // COUPLING: Must know their method signatures
        // COUPLING: Must know the order of operations
        // COUPLING: Must handle each service's errors
        
        await this.emailService.sendOrderConfirmation(order);
        await this.inventoryService.reserveItems(order.items);
        await this.analyticsService.trackPurchase(order);
        await this.warehouseService.createPickList(order);
        await this.fraudService.analyze(order);
        await this.loyaltyService.awardPoints(order.customerId, order.totalAmount);
        
        return order;
    }
}
 
/**
 * Problems with this coupling:
 * 
 * 1. KNOWLEDGE: OrderService must know about 6 other services
 * 
 * 2. CHANGES: Adding a new reaction (e.g., SMS notification) requires:
 *    - Adding new constructor parameter
 *    - Adding new method call
 *    - Modifying OrderService code
 *    - Redeploying OrderService
 * 
 * 3. TESTING: Must mock 6 dependencies for unit tests
 * 
 * 4. FAILURES: If emailService is down:
 *    - Does the entire operation fail?
 *    - Does it continue with partial success?
 *    - OrderService must contain this logic
 * 
 * 5. PERFORMANCE: All operations are serial (can parallelize, but OrderService
 *    must manage the complexity)
 * 
 * 6. ORDERING: What if warehouseService needs inventory reserved first?
 *    OrderService must encode this business logic
 */

Coupling Grows Over Time

The Cost of Coupling

Coupling imposes concrete costs that compound over time. Understanding these costs motivates the effort required to achieve decoupling.

The Ripple Effect

In coupled systems, changes propagate like ripples in a pond. A small change in one component forces changes in others, which force changes in others, and so on.

ripple-effect.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * The Ripple Effect of Coupling
 * 
 * Scenario: The EmailService team decides to add rate limiting.
 * They change the method signature:
 * 
 * BEFORE: sendEmail(to: string, subject: string, body: string)
 * AFTER:  sendEmail(to: string, subject: string, body: string, options?: EmailOptions)
 * 
 * This is a COMPATIBLE change. But watch the ripple...
 */
 
// Version 1: Original EmailService
class EmailServiceV1 {
    async sendEmail(to: string, subject: string, body: string): Promise<void> {
        await this.transport.send({ to, subject, body });
    }
}
 
// Version 2: Added priority support
class EmailServiceV2 {
    async sendEmail(
        to: string,
        subject: string,
        body: string,
        options?: { priority?: 'high' | 'normal' | 'low' }
    ): Promise<void> {
        await this.transport.send({ to, subject, body, ...options });
    }
}
 
// Now OrderService wants to send high-priority emails for large orders
class OrderServiceUpdated {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Need to know about EmailService's new options structure
        const priority = order.totalAmount > 1000 ? 'high' : 'normal';
        
        await this.emailService.sendEmail(
            order.customerEmail,
            'Order Confirmation',
            this.generateBody(order),
            { priority }  // Must know EmailService's interface details
        );
        
        return order;
    }
}
 
/**
 * The "small" EmailService change cascaded to:
 * 
 * 1. OrderService needs updating (to use priority feature)
 * 2. ShipmentService needs updating (track shipping emails need high priority)
 * 3. ReturnService needs updating
 * 4. PasswordResetService needs updating
 * 5. MarketingService needs updating (promotions are low priority)
 * 
 * Each service must:
 * - Know about the new options structure
 * - Decide what priority to use
 * - Update their integration tests
 * - Coordinate deployment timing
 * 
 * A "simple" additive change becomes 6 deployments.
 */

Business Costs of Coupling

•Slower Delivery — Changes require coordinated updates across multiple teams and services. What should be a 1-day fix becomes a 2-week project.
•Higher Risk — Each change touches more code, increasing the chance of bugs. Deployments become scary because the blast radius is large.
•Reduced Agility — Business requests like 'add SMS notifications' become major undertakings instead of simple additions.
•Testing Complexity — Testing one component requires setting up or mocking many others. Test suites become slow and brittle.
•Team Dependencies — Team A can't ship until Team B updates their service. Calendar tetris replaces independent progress.
•Knowledge Silos — Developers must understand the entire dependency graph to make safe changes, limiting who can contribute.

Conway's Law in Action

How Pub-Sub Achieves Decoupling

The Publish-Subscribe pattern achieves decoupling through indirection and inversion of dependency. Let's see how this works.

Before: Direct Dependencies

before-pubsub.ts
TypeScript
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
/**
 * BEFORE: Direct Dependencies
 * 
 * OrderService => EmailService
 * OrderService => InventoryService
 * OrderService => AnalyticsService
 * 
 * Changes flow FROM OrderService TO each dependency.
 * Adding new reactions requires modifying OrderService.
 */
class OrderService {
    constructor(
        private readonly emailService: EmailService,
        private readonly inventoryService: InventoryService,
        private readonly analyticsService: AnalyticsService
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Direct calls create coupling
        await this.emailService.sendOrderConfirmation(order);
        await this.inventoryService.reserveItems(order.items);
        await this.analyticsService.trackPurchase(order);
        
        return order;
    }
}
 
/**
 * Dependency Graph:
 * 
 *                    ┌─────────────┐
 *                    │ OrderService │
 *                    └──────┬──────┘
 *                           │
 *          ┌────────────────┼────────────────┐
 *          ▼                ▼                ▼
 *   ┌────────────┐  ┌────────────────┐  ┌──────────────┐
 *   │EmailService│  │InventoryService│  │AnalyticsService│
 *   └────────────┘  └────────────────┘  └──────────────┘
 * 
 * OrderService KNOWS about all three services.
 * Adding a 4th service requires modifying OrderService.
 */

After: Event-Based Decoupling

after-pubsub.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
/**
 * AFTER: Event-Based Decoupling
 * 
 * OrderService => EventBus (publishes OrderPlaced)
 * EmailSubscriber <= EventBus (listens for OrderPlaced)
 * InventorySubscriber <= EventBus (listens for OrderPlaced)
 * AnalyticsSubscriber <= EventBus (listens for OrderPlaced)
 * 
 * OrderService knows NOTHING about subscribers.
 * Subscribers know NOTHING about OrderService.
 * Both know only about the event contract.
 */
class OrderService {
    constructor(
        private readonly eventBus: IEventBus  // Only dependency: the bus
    ) {}
    
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Publish event - doesn't know who listens
        await this.eventBus.publish({
            eventType: 'OrderPlaced',
            eventId: generateUUID(),
            occurredAt: new Date(),
            aggregateId: order.id,
            payload: {
                orderId: order.id,
                customerId: order.customerId,
                items: order.items,
                totalAmount: order.totalAmount,
                customerEmail: order.customerEmail
            }
        });
        
        return order;
    }
}
 
// Subscribers register themselves - OrderService doesn't know about them
class EmailSubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.sendConfirmationEmail(event.payload);
    }
}
 
class InventorySubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.reserveInventory(event.payload.items);
    }
}
 
class AnalyticsSubscriber implements ISubscriber<DomainEvent> {
    subscribedEventTypes() { return ['OrderPlaced']; }
    
    async handle(event: DomainEvent): Promise<void> {
        await this.trackPurchase(event.payload);
    }
}
 
/**
 * New Dependency Graph:
 * 
 *   ┌─────────────┐                          ┌────────────────────┐
 *   │ OrderService │ ──publishes──►          │                    │
 *   └─────────────┘               ▼          │                    │
 *                           ┌───────────┐    │   ┌──────────────┐ │
 *                           │ EventBus  │◄───┼───│EmailSubscriber│ │
 *                           │           │    │   └──────────────┘ │
 *                           │OrderPlaced│◄───┼───│InventorySub  │ │
 *                           │  Event    │    │   └──────────────┘ │
 *                           │           │◄───┼───│AnalyticsSub  │ │
 *                           └───────────┘    │   └──────────────┘ │
 *                                            │                    │
 *                                            └─ Subscribers self-register
 * 
 * OrderService knows ONLY about EventBus.
 * Adding a 4th subscriber requires ZERO changes to OrderService.
 * Each subscriber can be developed, tested, deployed independently.
 */

What Pub-Sub Decouples

•Identity Decoupling — Publishers don't know subscriber identities. Subscribers don't know publisher identities.
•Location Decoupling — Publishers and subscribers can be in the same process, different processes, or different machines.
•Time Decoupling — With persistent message queues, publishers and subscribers don't need to be running simultaneously.
•Cardinality Decoupling — One event can trigger zero, one, or many reactions. The publisher doesn't care.
•Interface Decoupling — Subscribers don't call publisher methods. They react to the event contract, not the publisher's API.

Measuring Coupling Reduction

Let's quantify how pub-sub reduces coupling with concrete metrics.

Afferent and Efferent Coupling

Afferent Coupling (Ca): Number of modules that depend ON this module
Efferent Coupling (Ce): Number of modules this module depends ON

Instability (I) = Ce / (Ca + Ce)

I = 0: Fully stable (everyone depends on it, changes are costly)
I = 1: Fully unstable (depends on everyone, easy to change)

Coupling Metrics: Before vs After Pub-Sub
Metric	OrderService (Before)	OrderService (After)	Change
Efferent Coupling (Ce)	6 (knows 6 services)	1 (knows only EventBus)	🟢 -5 dependencies
Lines to modify to add service	~10 (new constructor param, method call)	0	🟢 Zero changes
Import statements	6 (one per service)	1 (IEventBus)	🟢 -5 imports
Constructor parameters	6	1	🟢 -5 parameters
Test mocks required	6	1	🟢 -5 mocks

Change Impact Analysis

Consider the impact of a common change: adding SMS notifications for orders.

Direct Coupling

•
1. Create SMSService class
•
1. Add constructor parameter to OrderService
•
1. Add method call to OrderService.placeOrder()
•
1. Update OrderService tests
•
1. Update OrderService deployment
•
1. Coordinate release with Order team
•Files changed: 4+
•Teams involved: 2
•Risk: Moderate (OrderService changes)

Pub-Sub Decoupling

•
1. Create SMSSubscriber class
•
1. Register with event bus
•
1. Done
•
•
•
•Files changed: 1-2
•Teams involved: 1
•Risk: Low (OrderService unchanged)

The Open-Closed Principle in Action

Pub-Sub embodies the Open-Closed Principle: the system is OPEN for extension (new subscribers) but CLOSED for modification (existing code unchanged). You extend behavior by adding, not by editing.

Types of Decoupling in Pub-Sub

The Publish-Subscribe pattern provides three distinct forms of decoupling. Understanding each helps you leverage them appropriately.

1. Space Decoupling (Location Independence)

Publishers and subscribers don't need to know each other's locations. They could be:

In the same process (in-memory event bus)
Different processes on the same machine
Different machines in the same data center
Geographically distributed across the globe

The only requirement is connectivity to the event bus/broker.

space-decoupling.ts
TypeScript
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
/**
 * Space Decoupling: Location Independence
 * 
 * These components work regardless of where they're deployed.
 */
 
// Publisher: Could run anywhere
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // Publishes to event bus - doesn't care where it goes
        await this.eventBus.publish(createOrderPlacedEvent(order));
        
        return order;
    }
}
 
// Subscriber: Could run anywhere
class EmailNotificationSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Processes event - doesn't care where it came from
        await this.sendEmail(event.payload.customerEmail);
    }
}
 
/**
 * Deployment Possibilities:
 * 
 * Scenario 1: Monolith
 *   [Process 1]
 *   ├── OrderService (publisher)
 *   ├── InMemoryEventBus
 *   └── EmailSubscriber
 * 
 * Scenario 2: Microservices, Same Region
 *   [Order Service Container] ──► [Kafka Cluster] ──► [Email Service Container]
 * 
 * Scenario 3: Global Distribution
 *   [US-East: Order Service] ──► [Global Kafka] ──► [EU-West: Email Service]
 * 
 * The code doesn't change. Only infrastructure configuration.
 */

2. Time Decoupling (Temporal Independence)

With durable message queues, publishers and subscribers don't need to be running simultaneously. Events persist until consumed.

time-decoupling.ts
TypeScript
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
/**
 * Time Decoupling: Temporal Independence
 * 
 * With durable event storage, timing doesn't matter.
 */
 
// Scenario: Publisher runs but subscriber is down
async function handleOrderDuringSubscriberDowntime() {
    // 10:00 AM: OrderService publishes
    await orderService.placeOrder(command);
    // Event is stored in Kafka/RabbitMQ
    
    // 10:00 AM - 11:00 AM: EmailService is down for maintenance
    // Events queue up in the broker
    
    // 11:00 AM: EmailService comes back online
    // Broker delivers queued events
    // Customer receives email an hour late, but receives it
}
 
// Benefits:
// 1. Maintenance windows don't cause data loss
// 2. Subscriber can process at its own pace
// 3. Traffic spikes are absorbed by the queue
// 4. Subscribers can "catch up" after downtime
 
// Configuration for time decoupling (Kafka example)
const kafkaConfig = {
    // Events retained for 7 days
    'log.retention.hours': 168,
    
    // Subscribers can rewind and replay
    'auto.offset.reset': 'earliest',
};
 
// Configuration for time decoupling (RabbitMQ example)
const rabbitQueue = {
    // Queue survives broker restart
    durable: true,
    
    // Messages survive broker restart
    persistent: true,
    
    // Keep up to 1M messages or 1GB
    maxLength: 1000000,
    maxLengthBytes: 1073741824
};

3. Synchronization Decoupling (Flow Independence)

Publishers don't block waiting for subscribers. Each subscriber processes at its own pace.

sync-decoupling.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
/**
 * Synchronization Decoupling: Flow Independence
 * 
 * Publisher completes immediately. Subscribers proceed independently.
 */
 
// Publisher: Returns quickly
class OrderService {
    async placeOrder(command: PlaceOrderCommand): Promise<Order> {
        const order = await this.createOrder(command);
        
        // This returns immediately after message is queued
        // Publisher doesn't wait for ANY subscriber to finish
        await this.eventBus.publish(createOrderPlacedEvent(order));
        
        // Response returned to user: ~50ms
        return order;
    }
}
 
// Fast subscriber: Processes in 100ms
class AnalyticsSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Quick fire-and-forget to analytics service
        await this.analytics.track(event.payload);
    }
}
 
// Slow subscriber: Processes in 5 seconds
class ReportGenerationSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Complex PDF generation, database aggregations
        await this.generateOrderReport(event.payload);
        await this.storeInArchive(event.payload);
    }
}
 
// Very slow subscriber: Processes in 30 seconds
class ExternalSystemSyncSubscriber {
    async handle(event: OrderPlacedEvent): Promise<void> {
        // Slow external API with rate limiting
        await this.syncToLegacyERP(event.payload);
        await this.syncToExternalCRM(event.payload);
    }
}
 
/**
 * Flow Analysis:
 * 
 * Without Pub-Sub (synchronous calls):
 *   User waits: 50ms + 100ms + 5000ms + 30000ms = 35.15 seconds
 *   Terrible UX. API timeout likely.
 * 
 * With Pub-Sub:
 *   User waits: 50ms (just order creation + publish)
 *   Subscribers process in parallel in background
 *   User gets immediate response
 * 
 * The slow subscriber doesn't slow down:
 *   - The publisher
 *   - Other subscribers
 *   - The user experience
 */

Trade-offs of Decoupling

Decoupling isn't free. It introduces trade-offs that you must understand and manage. Being honest about these trade-offs leads to better architectural decisions.

Complexity Trade-offs

Decoupling Trade-offs
Benefit	Trade-off	Mitigation
Independence from subscriber failures	Harder to know if processing succeeded	Dead letter queues, monitoring, alerts
Easy to add new reactions	Harder to see what happens when event fires	Event documentation, tracing tools
Asynchronous processing	Eventual consistency (not immediate)	Design for eventual consistency explicitly
No direct method coupling	Must maintain event contracts carefully	Event versioning, schema registry
Location independence	Network failures, latency concerns	Retries, idempotency, timeout handling

The Debuggability Challenge

In a directly coupled system, you can trace execution through a single call stack. In an event-driven system, the flow is distributed and harder to follow.

debuggability-challenge.ts
TypeScript
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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
/**
 * Debuggability Challenge
 * 
 * In coupled code, you can trace the full flow:
 */
 
// Coupled: Easy to trace (but hard to change)
async function placeOrderCoupled(command: PlaceOrderCommand) {
    const order = await createOrder(command);          // Line 1
    await emailService.send(order);                    // Line 2
    await inventoryService.reserve(order);             // Line 3
    await analyticsService.track(order);               // Line 4
    return order;                                      // Line 5
}
// Stack trace shows exactly where it failed: line 3, inventoryService
 
// Event-driven: Harder to trace (but easier to change)
async function placeOrderEventDriven(command: PlaceOrderCommand) {
    const order = await createOrder(command);          // Line 1
    await eventBus.publish(orderPlacedEvent);          // Line 2
    return order;                                      // Line 3
}
// Stack trace stops at line 2
// What happened after? Which subscribers ran? Which failed?
// Need distributed tracing to see full picture
 
/**
 * Mitigation: Correlation IDs and Distributed Tracing
 */
interface TraceableEvent extends DomainEvent {
    readonly correlationId: string;  // Links all related events
    readonly causationId: string;    // What caused this event
    readonly traceId: string;        // Spans entire request lifecycle
}
 
// All subscribers propagate tracing context
class TracedEmailSubscriber implements ISubscriber<TraceableEvent> {
    async handle(event: TraceableEvent): Promise<void> {
        // Create child span linked to parent trace
        const span = tracer.startSpan('email.send', {
            childOf: event.traceId,
            tags: {
                'event.id': event.eventId,
                'event.type': event.eventType,
                'correlation.id': event.correlationId
            }
        });
        
        try {
            await this.sendEmail(event.payload);
            span.setStatus('ok');
        } catch (error) {
            span.setStatus('error');
            span.log({ error: error.message });
            throw error;
        } finally {
            span.finish();
        }
    }
}
 
// Now tracing tools (Jaeger, Zipkin, Datadog) show:
// [OrderService.placeOrder] 50ms
//   └── [EventBus.publish] 5ms
//       ├── [EmailSubscriber.handle] 200ms ✓
//       ├── [InventorySubscriber.handle] 150ms ✗ (error)
//       └── [AnalyticsSubscriber.handle] 30ms ✓

Invest in Observability

Event-driven systems require stronger observability. Budget for distributed tracing, event logging, and monitoring dashboards. The debugging difficulty is real, but it's solvable with proper tooling.

When NOT to Decouple

Decoupling isn't always the right choice. Some scenarios call for direct coupling:

Keep Direct Coupling When

•Immediate consistency is required — Payment must be confirmed before order confirmation. Don't use eventual consistency for critical paths.
•Order of operations matters and is complex — If step B must happen exactly after step A, direct calls make this explicit.
•The relationship is truly one-to-one — If only one thing ever reacts to an event, the indirection may not be worth it.
•Debugging simplicity is paramount — Early-stage startups may prefer debuggability over extensibility.
•The domain is well-understood and stable — If you're confident about the behavior and it won't change, coupling is simpler.

Summary: Coupling and Decoupling

Key Takeaways

•Coupling measures dependency — High coupling means changes cascade across the system.
•Direct coupling has real costs — Slower delivery, higher risk, reduced agility, complex testing.
•Pub-Sub achieves decoupling through indirection — Publishers and subscribers know only the event contract, not each other.
•Three types of decoupling — Space (location), time (temporal), and synchronization (flow).
•Decoupling has trade-offs — Eventual consistency, debugging complexity, infrastructure needs.
•Measure coupling reduction — Use metrics like efferent coupling and change impact analysis.
•Don't decouple everything — Direct coupling is appropriate when consistency, ordering, or simplicity are critical.

What's next:

Page Complete

3 / 4