System Design (LLD)Event-Driven Design

Introduction to Event-Driven Design

LevelIntermediate

Duration60 mins

TopicEvent-Driven Design

3 / 4

Benefits of Event-Driven Approach

Why Architecture Patterns Matter

Understanding what event-driven design is matters little if we don't understand why we'd choose it. Every architectural pattern involves trade-offs, and event-driven design is no exception. The key is understanding when the benefits outweigh the costs.

This page examines the concrete benefits of event-driven design—not abstract theory, but tangible engineering advantages that affect how you build, maintain, and evolve software. By the end, you'll understand precisely what you gain by adopting event-driven patterns and be equipped to articulate these benefits to stakeholders.

What You Will Learn

By the end of this page, you will understand the five major benefits of event-driven design: loose coupling, extensibility without modification, improved resilience, enhanced testability, and better separation of concerns. You'll see concrete examples of each benefit and understand how they compound to create more maintainable systems.

Benefit 1: Loose Coupling Between Components

Loose coupling is the most fundamental benefit of event-driven design. When components communicate through events, they become independent actors that can evolve, scale, and fail independently.

What is coupling?

Coupling measures how much one component knows about, depends on, or is affected by another. High coupling means changes ripple across the system. Low coupling means components are isolated.

How events reduce coupling:

No direct references. Publishers don't import, reference, or know about subscribers. They only know about events.
No shared models. Each component can have its own internal model. They only share the event contract.
No operational dependency. Publishers don't wait for subscribers. They're not affected by subscriber availability or performance.

Tight Coupling (Direct Calls)

•OrderService imports InventoryService
•OrderService imports PaymentService
•OrderService imports EmailService
•OrderService knows 3 interfaces
•Changing any service might break OrderService
•Testing requires mocking all 3 dependencies
•OrderService is a bottleneck

Loose Coupling (Events)

•OrderService knows only EventDispatcher
•OrderService publishes OrderPlaced event
•Subscribers handle their concerns independently
•OrderService knows 1 interface (EventDispatcher)
•Changing subscribers doesn't affect OrderService
•Testing requires only mocking EventDispatcher
•OrderService remains focused and simple

coupling-comparison.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
// ===== TIGHTLY COUPLED: OrderService knows about everyone =====
class TightlyCouplededOrderService {
    constructor(
        private inventoryService: InventoryService,  // Direct dependency
        private paymentService: PaymentService,      // Direct dependency
        private emailService: EmailService,          // Direct dependency
        private analyticsService: AnalyticsService,  // Direct dependency
        private fraudService: FraudService,          // Direct dependency
    ) {}
    
    async placeOrder(order: Order): Promise<void> {
        // OrderService must orchestrate all these calls
        // It knows about 5 different interfaces
        // Changes to ANY of these affects this class
        
        await this.inventoryService.reserve(order.items);
        await this.paymentService.charge(order.customerId, order.total);
        await this.emailService.sendConfirmation(order);
        await this.analyticsService.trackOrder(order);
        await this.fraudService.recordTransaction(order);
        
        // Adding a new reaction (like loyalty points) means:
        // 1. Add new dependency to constructor
        // 2. Add new method call here
        // 3. Update all tests to mock new dependency
    }
}
 
// ===== LOOSELY COUPLED: OrderService knows only about events =====
class LooselyCoupledOrderService {
    constructor(
        private eventDispatcher: EventDispatcher,  // Single dependency
    ) {}
    
    async placeOrder(order: Order): Promise<void> {
        // Core business logic. Order is created and saved.
        await this.orderRepository.save(order);
        
        // Single event published. We're done.
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: {
                orderId: order.id,
                customerId: order.customerId,
                items: order.items,
                total: order.total,
            },
        });
        
        // We don't know or care:
        // - Who is listening
        // - What they will do
        // - Whether they succeed or fail
        // - How many there are
        
        // Adding a new reaction means:
        // 1. Create new handler (separate file/class)
        // 2. Subscribe it to "OrderPlaced"
        // NO CHANGES to OrderService!
    }
}
 
// Each handler is independent—OrderService doesn't know about them
class InventoryHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.inventoryService.reserve(event.payload.items);
    }
}
 
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.emailService.sendConfirmation(event.payload);
    }
}
 
// Handlers can be added without touching OrderService
class LoyaltyPointsHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const points = Math.floor(event.payload.total);
        await this.loyaltyService.awardPoints(event.payload.customerId, points);
    }
}

Coupling Metrics

In the tightly coupled version, OrderService has afferent coupling (incoming dependencies) from its callers AND efferent coupling (outgoing dependencies) to 5 services. In the loosely coupled version, it has efferent coupling only to EventDispatcher—a 5:1 reduction. This isn't just cleaner; it's more maintainable, testable, and evolvable.

Benefit 2: Extensibility Without Modification

Perhaps the most powerful practical benefit of event-driven design is the ability to extend system behavior without modifying existing code. This is the Open/Closed Principle applied at the architectural level.

The Traditional Extension Problem:

In tightly coupled systems, adding new behavior requires modifying existing components. Each modification risks introducing bugs, requires re-testing the modified component, and creates code churn in stable areas.

The Event-Driven Solution:

With events, new behavior is added by creating new subscribers. The existing publishers remain untouched—unchanged, untested, stable. You extend the system by adding code, not changing it.

Real-World Scenario: E-Commerce Order Processing

Imagine your e-commerce platform needs to add new features over time:

Feature	Traditional Approach	Event-Driven Approach
Fraud detection	Modify OrderService to call FraudService	Add FraudDetectionHandler subscribing to OrderPlaced
Loyalty points	Modify OrderService to call LoyaltyService	Add LoyaltyHandler subscribing to OrderPlaced
Partner notifications	Modify OrderService to call PartnerAPI	Add PartnerNotificationHandler
A/B testing	Modify OrderService to call ExperimentService	Add ExperimentTrackingHandler
Audit logging	Modify OrderService to call AuditService	Add AuditLogHandler

With the traditional approach, each new feature touches OrderService. After five features, OrderService has become a kitchen sink—harder to understand, test, and maintain.

With the event-driven approach, OrderService is unchanged. Five new handler classes exist, each focused on one concern, each tested independently.

extensibility-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
61
62
63
64
65
66
67
68
69
70
71
// ===== OrderService: Written in 2020, unchanged since =====
class OrderService {
    constructor(private eventDispatcher: EventDispatcher) {}
    
    async placeOrder(order: Order): Promise<Order> {
        // Core logic—hasn't changed in years
        await this.orderRepository.save(order);
        
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: { orderId: order.id, /* ... */ },
        });
        
        return order;
    }
}
 
// ===== Handler added in 2021: Fraud Detection =====
// OrderService unchanged
class FraudDetectionHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const riskScore = await this.fraudService.calculateRisk(event.payload);
        if (riskScore > FRAUD_THRESHOLD) {
            await this.alertService.flagOrder(event.payload.orderId);
        }
    }
}
 
// ===== Handler added in 2022: Loyalty Points =====
// OrderService unchanged
class LoyaltyPointsHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const points = this.calculatePoints(event.payload.total);
        await this.loyaltyService.awardPoints(event.payload.customerId, points);
    }
}
 
// ===== Handler added in 2023: Partner Notifications =====
// OrderService unchanged
class PartnerNotificationHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const partners = await this.partnerService.getAffiliatedPartners(
            event.payload.items
        );
        for (const partner of partners) {
            await this.partnerAPI.notifyOrder(partner.id, event.payload);
        }
    }
}
 
// ===== Handler added in 2024: AI Recommendation Update =====
// OrderService STILL unchanged after 4 years
class RecommendationUpdateHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.mlPipeline.updateUserPreferences(
            event.payload.customerId,
            event.payload.items
        );
    }
}
 
// ===== Configuration: Wire handlers at app startup =====
// This is the ONLY place that changes when adding handlers
function configureEventHandlers(dispatcher: EventDispatcher) {
    dispatcher.subscribe("OrderPlaced", new EmailHandler());
    dispatcher.subscribe("OrderPlaced", new InventoryHandler());
    dispatcher.subscribe("OrderPlaced", new FraudDetectionHandler());      // 2021
    dispatcher.subscribe("OrderPlaced", new LoyaltyPointsHandler());       // 2022
    dispatcher.subscribe("OrderPlaced", new PartnerNotificationHandler()); // 2023
    dispatcher.subscribe("OrderPlaced", new RecommendationUpdateHandler()); // 2024
}

Open/Closed Principle in Action

The Open/Closed Principle states: "Software entities should be open for extension, but closed for modification." Event-driven design achieves this naturally. Publishers are closed (stable, unchanged), while the system is open (new handlers extend behavior). This reduces risk and enables parallel development.

Benefit 3: Improved Resilience

Event-driven systems are inherently more resilient than tightly coupled alternatives. This resilience manifests in several ways:

Failure Isolation:

When components communicate through events, failures are contained. If one handler fails, other handlers continue processing. The publisher doesn't see the failure. The system degrades gracefully rather than collapsing entirely.

Temporal Decoupling:

Events don't require immediate processing. If a subscriber is temporarily unavailable (deployment, restart, overload), events can queue until it recovers. The publisher doesn't stall waiting for the subscriber.

Independent Scaling:

Each handler can scale independently based on its own resource needs. A slow analytics handler doesn't slow down a fast email handler. Different handlers can run on different infrastructure.

Resilience Characteristics: Tightly Coupled vs Event-Driven
Failure Scenario	Tightly Coupled System	Event-Driven System
Email service is down	Order placement fails or hangs	Order succeeds; email handler retries later
Analytics service is slow	Order placement slows down for everyone	Analytics handler queues up; orders unaffected
New handler has a bug	Might crash or corrupt the publisher	Only new handler fails; others continue
Subscriber deployment	Must coordinate with publisher downtime	Subscriber catches up after restart
Traffic spike	All services overloaded together	Each handler buffers and processes at capacity
Partial outage	Critical path blocked	Non-critical handlers fail; critical path proceeds

resilience-patterns.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
85
86
87
88
89
90
// ===== Resilient Event Dispatcher with Failure Isolation =====
 
class ResilientEventDispatcher {
    async dispatch(event: DomainEvent): Promise<void> {
        const handlers = this.getHandlers(event.type);
        
        // Process all handlers, capturing results
        const results = await Promise.allSettled(
            handlers.map(handler => this.safeHandle(handler, event))
        );
        
        // Analyze results for monitoring
        const failures = results.filter(r => r.status === "rejected");
        
        if (failures.length > 0) {
            // Log failures but don't propagate to publisher
            for (const failure of failures) {
                await this.handleFailure(event, failure.reason);
            }
        }
        
        // The event was successfully published
        // Individual handler failures are isolated
    }
    
    private async safeHandle(
        handler: EventHandler,
        event: DomainEvent
    ): Promise<void> {
        const timeout = 30000; // 30 second timeout per handler
        
        return Promise.race([
            handler.handle(event),
            new Promise<never>((_, reject) =>
                setTimeout(() => reject(new TimeoutError()), timeout)
            ),
        ]);
    }
    
    private async handleFailure(event: DomainEvent, error: Error): Promise<void> {
        // Strategy 1: Log for observability
        console.error(`Handler failed for ${event.type}:`, error);
        
        // Strategy 2: Send to dead-letter queue for retry/investigation
        await this.deadLetterQueue.enqueue({
            event,
            error: error.message,
            timestamp: new Date(),
        });
        
        // Strategy 3: Alert if failure rate exceeds threshold
        await this.alerting.checkThreshold(event.type);
    }
}
 
// ===== Handler with its own resilience =====
 
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    constructor(
        private emailService: EmailService,
        private retryQueue: RetryQueue,
    ) {}
    
    async handle(event: OrderPlacedEvent): Promise<void> {
        try {
            await this.emailService.sendOrderConfirmation(event.payload);
        } catch (error) {
            if (this.isRetryable(error)) {
                // Queue for retry—this handler handles its own failures
                await this.retryQueue.enqueue({
                    event,
                    attemptNumber: 1,
                    maxAttempts: 5,
                    backoffMs: 60000,
                });
            } else {
                // Non-retryable error—log and give up
                console.error("Email permanently failed:", error);
            }
            
            // Either way, we don't throw—don't affect other handlers
        }
    }
    
    private isRetryable(error: Error): boolean {
        return error instanceof TemporaryFailureError ||
               error instanceof RateLimitError ||
               error instanceof TimeoutError;
    }
}

Bulkhead Pattern

Event-driven design naturally implements the Bulkhead pattern from resilience engineering. Just as ship bulkheads contain flooding to one compartment, event handlers isolate failures to one component. A problem in the analytics handler doesn't sink the order processing capability.

Benefit 4: Enhanced Testability

Event-driven design dramatically improves testability at multiple levels:

Publisher Testing (Simple):

To test that a publisher correctly raises events, you only need to verify that the right event was dispatched with the right data. You don't need to mock 5 different services—just the event dispatcher.

Handler Testing (Isolated):

Each handler can be tested in complete isolation. Give it an event, verify its behavior. The handler doesn't know or care about the publisher; it just processes events.

Integration Testing (Flexible):

You can test the full flow by wiring up publishers to handlers with a test dispatcher. Or you can test subsets by only subscribing specific handlers. This flexibility enables thorough yet focused testing.

testing-event-driven.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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
// ===== TESTING PUBLISHERS: Verify correct events are raised =====
 
describe("OrderService", () => {
    it("should publish OrderPlaced event when order is created", async () => {
        // Arrange: Simple mock dispatcher that captures events
        const capturedEvents: DomainEvent[] = [];
        const mockDispatcher: EventDispatcher = {
            dispatch: async (event) => { capturedEvents.push(event); },
        };
        
        const orderService = new OrderService(mockDispatcher, mockRepo);
        
        // Act: Place an order
        await orderService.placeOrder({
            customerId: "customer-123",
            items: [{ productId: "product-1", quantity: 2 }],
        });
        
        // Assert: Correct event was published
        expect(capturedEvents).toHaveLength(1);
        expect(capturedEvents[0].type).toBe("OrderPlaced");
        expect(capturedEvents[0].payload.customerId).toBe("customer-123");
        
        // We DON'T need to mock InventoryService, EmailService, etc.
        // because OrderService doesn't know about them!
    });
    
    it("should not publish event if order validation fails", async () => {
        const capturedEvents: DomainEvent[] = [];
        const mockDispatcher = { dispatch: async (e) => { capturedEvents.push(e); } };
        
        const orderService = new OrderService(mockDispatcher, mockRepo);
        
        // Act: Try to place invalid order
        await expect(
            orderService.placeOrder({ customerId: "", items: [] })
        ).rejects.toThrow(ValidationError);
        
        // Assert: No event was published
        expect(capturedEvents).toHaveLength(0);
    });
});
 
// ===== TESTING HANDLERS: Isolated, focused tests =====
 
describe("EmailHandler", () => {
    it("should send confirmation email when OrderPlaced event received", async () => {
        // Arrange: Mock only what this handler needs
        const mockEmailService = {
            sendOrderConfirmation: jest.fn().mockResolvedValue(undefined),
        };
        
        const handler = new EmailHandler(mockEmailService);
        
        // Create a test event—no need for full system
        const event: OrderPlacedEvent = {
            type: "OrderPlaced",
            occurredAt: new Date(),
            payload: {
                orderId: "order-123",
                customerId: "customer-456",
                customerEmail: "customer@example.com",
            },
        };
        
        // Act: Handle the event
        await handler.handle(event);
        
        // Assert: Email was sent with correct data
        expect(mockEmailService.sendOrderConfirmation).toHaveBeenCalledWith({
            email: "customer@example.com",
            orderId: "order-123",
        });
    });
    
    it("should not throw when email service fails", async () => {
        // Handler should be resilient—test that!
        const mockEmailService = {
            sendOrderConfirmation: jest.fn().mockRejectedValue(new Error("SMTP down")),
        };
        
        const handler = new EmailHandler(mockEmailService);
        
        // Act & Assert: No exception thrown
        await expect(handler.handle(testEvent)).resolves.not.toThrow();
    });
});
 
// ===== TESTING INTEGRATION: Selective handler registration =====
 
describe("Order Placement Integration", () => {
    it("should trigger inventory and email handlers", async () => {
        // Arrange: Create real dispatcher with selected handlers
        const dispatcher = new SynchronousEventDispatcher();
        
        const mockInventoryService = { reserve: jest.fn().mockResolvedValue(undefined) };
        const mockEmailService = { sendOrderConfirmation: jest.fn().mockResolvedValue(undefined) };
        
        dispatcher.subscribe("OrderPlaced", new InventoryHandler(mockInventoryService));
        dispatcher.subscribe("OrderPlaced", new EmailHandler(mockEmailService));
        // Note: NOT subscribing analytics, fraud, etc.—focused test
        
        const orderService = new OrderService(dispatcher, realOrderRepo);
        
        // Act
        await orderService.placeOrder(validOrder);
        
        // Assert: Both handlers were triggered
        expect(mockInventoryService.reserve).toHaveBeenCalled();
        expect(mockEmailService.sendOrderConfirmation).toHaveBeenCalled();
    });
});

Testing Advantages Summary

•Fewer mocks per test. Publishers only need EventDispatcher mocked. Handlers only need their direct dependencies.
•Isolated test failures. A broken handler test doesn't indicate broken publisher—they're separate.
•Easy to add test coverage. New handlers get their own test file—no modification to existing tests.
•Flexible integration testing. Wire up subsets of handlers to test specific flows.
•Event-based assertions. You can assert on what events were published, not just final state.
•Replay-friendly. Captured events can be replayed to test handler behavior.

Test Pyramid Alignment

Event-driven design aligns well with the test pyramid. Unit tests for individual handlers (fast, many). Integration tests for publisher-handler flows (medium, fewer). End-to-end tests for full system (slow, minimal). The architectural separation makes each level cleaner.

Benefit 5: Separation of Concerns

Event-driven design naturally enforces separation of concerns—the principle that each component should have one reason to change and one responsibility to fulfill.

The Problem with Direct Calls:

In tightly coupled systems, the orchestrating component (like OrderService) accumulates concerns:

Primary business logic (creating orders)
Coordination logic (calling other services)
Error handling (what if inventory fails?)
Ordering logic (payment before inventory?)
Timeout handling (service too slow?)

The class becomes a "god object" that knows about everything.

The Event-Driven Solution:

With events, each component focuses on its core responsibility:

OrderService: Creating and validating orders
InventoryHandler: Reserving inventory
EmailHandler: Sending emails
Event Dispatcher: Routing events

No component needs to understand others' business logic. Each can be understood, modified, and tested in isolation.

separation-of-concerns.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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
// ===== BEFORE: OrderService has too many concerns =====
 
class GodOrderService {
    // Constructor with too many dependencies
    constructor(
        private orderRepo: OrderRepository,
        private inventory: InventoryService,
        private payment: PaymentService,
        private email: EmailService,
        private analytics: AnalyticsService,
        private fraud: FraudService,
    ) {}
    
    async placeOrder(orderData: OrderData): Promise<Order> {
        // CONCERN 1: Order creation and validation
        const order = new Order(orderData);
        if (!order.isValid()) {
            throw new ValidationError(order.validationErrors);
        }
        
        // CONCERN 2: Fraud detection
        const fraudScore = await this.fraud.calculateRisk(order);
        if (fraudScore > 0.8) {
            throw new FraudSuspectedError(order.id);
        }
        
        // CONCERN 3: Inventory management
        try {
            await this.inventory.reserve(order.items);
        } catch (error) {
            if (error instanceof OutOfStockError) {
                // CONCERN 4: User notification
                await this.email.sendOutOfStockNotification(order.customerId);
                throw error;
            }
            throw error;
        }
        
        // CONCERN 5: Payment processing
        try {
            await this.payment.charge(order.customerId, order.total);
        } catch (error) {
            // CONCERN 6: Compensating actions
            await this.inventory.release(order.items);
            await this.email.sendPaymentFailedNotification(order.customerId);
            throw error;
        }
        
        // CONCERN 7: Persistence
        await this.orderRepo.save(order);
        
        // CONCERN 8: Notifications
        await this.email.sendOrderConfirmation(order);
        
        // CONCERN 9: Analytics
        await this.analytics.trackOrder(order);
        
        return order;
        
        // This method has NINE concerns. It will only grow.
        // Every new feature adds more complexity here.
    }
}
 
// ===== AFTER: Each component has ONE concern =====
 
// OrderService: ONLY order creation and validation
class FocusedOrderService {
    constructor(
        private orderRepo: OrderRepository,
        private eventDispatcher: EventDispatcher,
    ) {}
    
    async placeOrder(orderData: OrderData): Promise<Order> {
        // ONLY concern: Create and validate order
        const order = new Order(orderData);
        if (!order.isValid()) {
            throw new ValidationError(order.validationErrors);
        }
        
        await this.orderRepo.save(order);
        
        // Announce it happened. That's it.
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: order.toEventPayload(),
        });
        
        return order;
    }
}
 
// FraudHandler: ONLY fraud detection
class FraudHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const score = await this.fraudService.calculateRisk(event.payload);
        if (score > 0.8) {
            await this.eventDispatcher.dispatch({
                type: "OrderFlagged",
                payload: { orderId: event.payload.orderId, reason: "fraud_risk" },
            });
        }
    }
}
 
// InventoryHandler: ONLY inventory reservation
class InventoryHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        try {
            await this.inventoryService.reserve(event.payload.items);
        } catch (error) {
            await this.eventDispatcher.dispatch({
                type: "InventoryReservationFailed",
                payload: { orderId: event.payload.orderId, reason: error.message },
            });
        }
    }
}
 
// EmailHandler: ONLY email sending
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.emailService.sendOrderConfirmation(event.payload);
    }
}
 
// Each handler: single responsibility, single reason to change
// EmailHandler changes when email logic changes
// InventoryHandler changes when inventory logic changes
// They never need to know about each other

Single Responsibility at Scale

The Single Responsibility Principle often gets diluted in tightly coupled systems. Event-driven design enforces it architecturally. If a handler does two things, it's easy to split into two handlers. If a god-class does ten things, refactoring is a major undertaking.

Benefit 6: Enabling Parallel Development

Event-driven design enables teams to work in parallel with minimal coordination. This is particularly valuable for larger organizations and complex projects.

The Coordination Problem:

In tightly coupled systems, adding a new feature often requires:

Modifying the central orchestrating component
Coordinating with the team that owns that component
Waiting for their review and merge
Potentially fixing integration conflicts

This creates bottlenecks and sequential development.

Event-Driven Parallelism:

With events, teams can work independently:

Team A publishes events from their domain
Team B creates handlers without touching Team A's code
Teams agree on event schemas (contracts)
Development proceeds in parallel

Development Workflow Comparison
Scenario	Tightly Coupled	Event-Driven
New team joins project	Must understand central orchestrator	Study relevant events; create handlers
New feature development	Modify shared component; coordinate merges	Create new handler in team's codebase
Bug in one handler	Might block releases of modified component	Fix in isolation; deploy independently
Different release cycles	All teams synchronized to shared component	Each handler released independently
Team A on vacation	Team B waits for code review	Team B creates handlers without Team A
Code ownership clarity	Shared component has unclear ownership	Each handler owned by one team

Event Contracts as API Boundaries:

In practice, events act as contracts between teams:

Producer teams define and document events they publish
Consumer teams subscribe to events they care about
The contract (event schema) is the only coordination point

As long as producers maintain backward compatibility of their events (adding optional fields rather than breaking changes), consumers can evolve independently.

This mirrors how APIs enable independent team development, but at a finer granularity—events are smaller, more focused contracts than full API surfaces.

Schema Evolution

Event schemas should be treated like public APIs. Use semantic versioning, maintain backward compatibility, and deprecate gracefully. Many teams use schema registries (like Avro, Protobuf, or JSON Schema) to formalize event contracts and ensure compatibility.

Benefit 7: Natural Auditing and Debugging

Events create a natural audit trail. Every significant action is recorded as an event, providing insight into what happened, when, and in what order.

Built-in History:

When you persist events (even just to logs), you automatically have:

A record of every significant state change
Timestamps for when things happened
Data snapshots at each point in time
The sequence of operations

Debugging Benefits:

Reproduction: Capture the events that led to a bug; replay them in development.
Timeline reconstruction: See exactly what events occurred before an issue.
Root cause analysis: Trace which event triggered which handler.
Production investigation: Query event logs to understand customer issues.

event-auditing.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
85
86
87
// ===== Auditing Event Dispatcher =====
// Automatically logs all events for audit and debugging
 
class AuditingEventDispatcher implements EventDispatcher {
    constructor(
        private innerDispatcher: EventDispatcher,
        private eventStore: EventStore,
        private logger: Logger,
    ) {}
    
    async dispatch(event: DomainEvent): Promise<void> {
        // Record the event for audit trail
        await this.eventStore.append({
            ...event,
            recordedAt: new Date(),
            correlationId: this.getCurrentCorrelationId(),
        });
        
        // Log for immediate visibility
        this.logger.info(`Event published: ${event.type}`, {
            eventId: event.eventId,
            aggregateId: event.aggregateId,
            occurredAt: event.occurredAt,
        });
        
        // Dispatch to actual handlers
        await this.innerDispatcher.dispatch(event);
    }
}
 
// ===== Querying Event History =====
 
class EventQueryService {
    constructor(private eventStore: EventStore) {}
    
    // What happened to this order?
    async getOrderHistory(orderId: string): Promise<DomainEvent[]> {
        return this.eventStore.findByAggregateId(orderId);
        // Returns: [OrderPlaced, PaymentProcessed, InventoryReserved, OrderShipped, ...]
    }
    
    // What happened in the last hour?
    async getRecentEvents(eventType?: string): Promise<DomainEvent[]> {
        return this.eventStore.findRecent({
            since: new Date(Date.now() - 60 * 60 * 1000),
            type: eventType,
        });
    }
    
    // Reproduce a bug: get events leading up to failure
    async getEventsForDebugging(
        startTime: Date,
        endTime: Date,
        correlationId?: string
    ): Promise<DomainEvent[]> {
        return this.eventStore.findInTimeRange({
            start: startTime,
            end: endTime,
            correlationId,
        });
    }
}
 
// ===== Usage: Customer Support Investigation =====
 
async function investigateCustomerIssue(orderId: string) {
    const events = await eventQueryService.getOrderHistory(orderId);
    
    console.log(`Order ${orderId} timeline:`);
    for (const event of events) {
        console.log(`  ${event.occurredAt.toISOString()} - ${event.type}`);
        console.log(`    Payload: ${JSON.stringify(event.payload)}`);
    }
    
    // Output:
    // Order order-123 timeline:
    //   2024-01-15T10:30:45Z - OrderPlaced
    //     Payload: { customerId: "cust-456", items: [...], total: 99.99 }
    //   2024-01-15T10:30:46Z - PaymentProcessed
    //     Payload: { orderId: "order-123", transactionId: "tx-789", amount: 99.99 }
    //   2024-01-15T10:30:47Z - InventoryReserved
    //     Payload: { orderId: "order-123", items: [...] }
    //   2024-01-15T10:31:15Z - ShippingLabelCreated
    //     Payload: { orderId: "order-123", trackingNumber: "1Z999..." }
    //   2024-01-16T14:22:00Z - OrderDelivered
    //     Payload: { orderId: "order-123", deliveredAt: "2024-01-16T14:22:00Z" }
}

Event Sourcing Connection

This natural audit trail is the foundation of Event Sourcing—a pattern where events become the source of truth, and current state is derived by replaying events. We'll explore Event Sourcing in a later module. For now, even without full Event Sourcing, persisting events provides significant debugging and auditing value.

The Trade-offs: What You Give Up

No architectural pattern is free. Event-driven design has real costs that must be weighed against its benefits.

Indirection and Complexity:

Following the code path is harder. You can't just "Go to Definition" from publisher to handler. You need to understand the subscription mechanism, search for handlers, and mentally trace the flow.

Real Trade-offs to Consider

•Harder to trace execution. Direct calls are explicit; event flows require searching for subscribers. New developers take longer to understand the system.
•Eventual consistency. If using async events, the system is eventually consistent. This adds complexity to UX and business logic.
•No return values. You can't get a response from an event. Complex workflows require multiple events or saga patterns.
•Ordering challenges. Handler execution order may be non-deterministic. If order matters, you need explicit sequencing.
•Debugging distributed flows. When handlers span services or processes, debugging requires distributed tracing infrastructure.
•Over-engineering risk. Not every interaction needs events. Simple direct calls are appropriate for cohesive operations.

Choose Wisely

Event-driven design is not universally better—it's a trade-off. Use it where decoupling and extensibility justify the added complexity. For simple, linear operations where you need responses and tight control, direct method calls are cleaner. The next page will help you decide when events are the right choice.

Summary: Benefits of Event-Driven Approach

We've explored the concrete benefits of event-driven design. Let's consolidate:

Key Benefits Summary

•Loose coupling. Publishers don't know about subscribers. Components evolve independently.
•Extensibility. New behavior via new handlers—no modification to existing code.
•Resilience. Failure isolation, temporal decoupling, independent scaling.
•Testability. Fewer mocks, isolated tests, flexible integration testing.
•Separation of concerns. Each handler has one responsibility, one reason to change.
•Parallel development. Teams work independently, coordinating only on event schemas.
•Auditing and debugging. Events provide natural history and audit trails.

But remember the trade-offs:

Indirection makes code harder to trace
Eventual consistency adds complexity
No return values complicates some workflows
Over-engineering is a real risk

The key is applying event-driven design where its benefits outweigh its costs.

What's next:

Now that we understand events vs commands and the benefits of events, the crucial question is: When should you actually use events? The next page provides decision frameworks for choosing between event-driven patterns and direct communication.

Page Complete

You now understand the concrete benefits of event-driven design: loose coupling, extensibility, resilience, testability, separation of concerns, parallel development, and auditing. You also understand the trade-offs. Next, we'll learn when to apply these patterns.

3 / 4

Loading learning content...

System Design (LLD)Event-Driven Design

Introduction to Event-Driven Design

LevelIntermediate

Duration60 mins

TopicEvent-Driven Design

3 / 4

Benefits of Event-Driven Approach

Why Architecture Patterns Matter

What You Will Learn

Benefit 1: Loose Coupling Between Components

Loose coupling is the most fundamental benefit of event-driven design. When components communicate through events, they become independent actors that can evolve, scale, and fail independently.

What is coupling?

Coupling measures how much one component knows about, depends on, or is affected by another. High coupling means changes ripple across the system. Low coupling means components are isolated.

How events reduce coupling:

No direct references. Publishers don't import, reference, or know about subscribers. They only know about events.
No shared models. Each component can have its own internal model. They only share the event contract.
No operational dependency. Publishers don't wait for subscribers. They're not affected by subscriber availability or performance.

Tight Coupling (Direct Calls)

•OrderService imports InventoryService
•OrderService imports PaymentService
•OrderService imports EmailService
•OrderService knows 3 interfaces
•Changing any service might break OrderService
•Testing requires mocking all 3 dependencies
•OrderService is a bottleneck

Loose Coupling (Events)

•OrderService knows only EventDispatcher
•OrderService publishes OrderPlaced event
•Subscribers handle their concerns independently
•OrderService knows 1 interface (EventDispatcher)
•Changing subscribers doesn't affect OrderService
•Testing requires only mocking EventDispatcher
•OrderService remains focused and simple

coupling-comparison.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
// ===== TIGHTLY COUPLED: OrderService knows about everyone =====
class TightlyCouplededOrderService {
    constructor(
        private inventoryService: InventoryService,  // Direct dependency
        private paymentService: PaymentService,      // Direct dependency
        private emailService: EmailService,          // Direct dependency
        private analyticsService: AnalyticsService,  // Direct dependency
        private fraudService: FraudService,          // Direct dependency
    ) {}
    
    async placeOrder(order: Order): Promise<void> {
        // OrderService must orchestrate all these calls
        // It knows about 5 different interfaces
        // Changes to ANY of these affects this class
        
        await this.inventoryService.reserve(order.items);
        await this.paymentService.charge(order.customerId, order.total);
        await this.emailService.sendConfirmation(order);
        await this.analyticsService.trackOrder(order);
        await this.fraudService.recordTransaction(order);
        
        // Adding a new reaction (like loyalty points) means:
        // 1. Add new dependency to constructor
        // 2. Add new method call here
        // 3. Update all tests to mock new dependency
    }
}
 
// ===== LOOSELY COUPLED: OrderService knows only about events =====
class LooselyCoupledOrderService {
    constructor(
        private eventDispatcher: EventDispatcher,  // Single dependency
    ) {}
    
    async placeOrder(order: Order): Promise<void> {
        // Core business logic. Order is created and saved.
        await this.orderRepository.save(order);
        
        // Single event published. We're done.
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: {
                orderId: order.id,
                customerId: order.customerId,
                items: order.items,
                total: order.total,
            },
        });
        
        // We don't know or care:
        // - Who is listening
        // - What they will do
        // - Whether they succeed or fail
        // - How many there are
        
        // Adding a new reaction means:
        // 1. Create new handler (separate file/class)
        // 2. Subscribe it to "OrderPlaced"
        // NO CHANGES to OrderService!
    }
}
 
// Each handler is independent—OrderService doesn't know about them
class InventoryHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.inventoryService.reserve(event.payload.items);
    }
}
 
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.emailService.sendConfirmation(event.payload);
    }
}
 
// Handlers can be added without touching OrderService
class LoyaltyPointsHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const points = Math.floor(event.payload.total);
        await this.loyaltyService.awardPoints(event.payload.customerId, points);
    }
}

Coupling Metrics

Benefit 2: Extensibility Without Modification

The Traditional Extension Problem:

The Event-Driven Solution:

With events, new behavior is added by creating new subscribers. The existing publishers remain untouched—unchanged, untested, stable. You extend the system by adding code, not changing it.

Real-World Scenario: E-Commerce Order Processing

Imagine your e-commerce platform needs to add new features over time:

Feature	Traditional Approach	Event-Driven Approach
Fraud detection	Modify OrderService to call FraudService	Add FraudDetectionHandler subscribing to OrderPlaced
Loyalty points	Modify OrderService to call LoyaltyService	Add LoyaltyHandler subscribing to OrderPlaced
Partner notifications	Modify OrderService to call PartnerAPI	Add PartnerNotificationHandler
A/B testing	Modify OrderService to call ExperimentService	Add ExperimentTrackingHandler
Audit logging	Modify OrderService to call AuditService	Add AuditLogHandler

With the traditional approach, each new feature touches OrderService. After five features, OrderService has become a kitchen sink—harder to understand, test, and maintain.

With the event-driven approach, OrderService is unchanged. Five new handler classes exist, each focused on one concern, each tested independently.

extensibility-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
61
62
63
64
65
66
67
68
69
70
71
// ===== OrderService: Written in 2020, unchanged since =====
class OrderService {
    constructor(private eventDispatcher: EventDispatcher) {}
    
    async placeOrder(order: Order): Promise<Order> {
        // Core logic—hasn't changed in years
        await this.orderRepository.save(order);
        
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: { orderId: order.id, /* ... */ },
        });
        
        return order;
    }
}
 
// ===== Handler added in 2021: Fraud Detection =====
// OrderService unchanged
class FraudDetectionHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const riskScore = await this.fraudService.calculateRisk(event.payload);
        if (riskScore > FRAUD_THRESHOLD) {
            await this.alertService.flagOrder(event.payload.orderId);
        }
    }
}
 
// ===== Handler added in 2022: Loyalty Points =====
// OrderService unchanged
class LoyaltyPointsHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const points = this.calculatePoints(event.payload.total);
        await this.loyaltyService.awardPoints(event.payload.customerId, points);
    }
}
 
// ===== Handler added in 2023: Partner Notifications =====
// OrderService unchanged
class PartnerNotificationHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const partners = await this.partnerService.getAffiliatedPartners(
            event.payload.items
        );
        for (const partner of partners) {
            await this.partnerAPI.notifyOrder(partner.id, event.payload);
        }
    }
}
 
// ===== Handler added in 2024: AI Recommendation Update =====
// OrderService STILL unchanged after 4 years
class RecommendationUpdateHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.mlPipeline.updateUserPreferences(
            event.payload.customerId,
            event.payload.items
        );
    }
}
 
// ===== Configuration: Wire handlers at app startup =====
// This is the ONLY place that changes when adding handlers
function configureEventHandlers(dispatcher: EventDispatcher) {
    dispatcher.subscribe("OrderPlaced", new EmailHandler());
    dispatcher.subscribe("OrderPlaced", new InventoryHandler());
    dispatcher.subscribe("OrderPlaced", new FraudDetectionHandler());      // 2021
    dispatcher.subscribe("OrderPlaced", new LoyaltyPointsHandler());       // 2022
    dispatcher.subscribe("OrderPlaced", new PartnerNotificationHandler()); // 2023
    dispatcher.subscribe("OrderPlaced", new RecommendationUpdateHandler()); // 2024
}

Open/Closed Principle in Action

Benefit 3: Improved Resilience

Event-driven systems are inherently more resilient than tightly coupled alternatives. This resilience manifests in several ways:

Failure Isolation:

Temporal Decoupling:

Independent Scaling:

Each handler can scale independently based on its own resource needs. A slow analytics handler doesn't slow down a fast email handler. Different handlers can run on different infrastructure.

Resilience Characteristics: Tightly Coupled vs Event-Driven
Failure Scenario	Tightly Coupled System	Event-Driven System
Email service is down	Order placement fails or hangs	Order succeeds; email handler retries later
Analytics service is slow	Order placement slows down for everyone	Analytics handler queues up; orders unaffected
New handler has a bug	Might crash or corrupt the publisher	Only new handler fails; others continue
Subscriber deployment	Must coordinate with publisher downtime	Subscriber catches up after restart
Traffic spike	All services overloaded together	Each handler buffers and processes at capacity
Partial outage	Critical path blocked	Non-critical handlers fail; critical path proceeds

resilience-patterns.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
85
86
87
88
89
90
// ===== Resilient Event Dispatcher with Failure Isolation =====
 
class ResilientEventDispatcher {
    async dispatch(event: DomainEvent): Promise<void> {
        const handlers = this.getHandlers(event.type);
        
        // Process all handlers, capturing results
        const results = await Promise.allSettled(
            handlers.map(handler => this.safeHandle(handler, event))
        );
        
        // Analyze results for monitoring
        const failures = results.filter(r => r.status === "rejected");
        
        if (failures.length > 0) {
            // Log failures but don't propagate to publisher
            for (const failure of failures) {
                await this.handleFailure(event, failure.reason);
            }
        }
        
        // The event was successfully published
        // Individual handler failures are isolated
    }
    
    private async safeHandle(
        handler: EventHandler,
        event: DomainEvent
    ): Promise<void> {
        const timeout = 30000; // 30 second timeout per handler
        
        return Promise.race([
            handler.handle(event),
            new Promise<never>((_, reject) =>
                setTimeout(() => reject(new TimeoutError()), timeout)
            ),
        ]);
    }
    
    private async handleFailure(event: DomainEvent, error: Error): Promise<void> {
        // Strategy 1: Log for observability
        console.error(`Handler failed for ${event.type}:`, error);
        
        // Strategy 2: Send to dead-letter queue for retry/investigation
        await this.deadLetterQueue.enqueue({
            event,
            error: error.message,
            timestamp: new Date(),
        });
        
        // Strategy 3: Alert if failure rate exceeds threshold
        await this.alerting.checkThreshold(event.type);
    }
}
 
// ===== Handler with its own resilience =====
 
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    constructor(
        private emailService: EmailService,
        private retryQueue: RetryQueue,
    ) {}
    
    async handle(event: OrderPlacedEvent): Promise<void> {
        try {
            await this.emailService.sendOrderConfirmation(event.payload);
        } catch (error) {
            if (this.isRetryable(error)) {
                // Queue for retry—this handler handles its own failures
                await this.retryQueue.enqueue({
                    event,
                    attemptNumber: 1,
                    maxAttempts: 5,
                    backoffMs: 60000,
                });
            } else {
                // Non-retryable error—log and give up
                console.error("Email permanently failed:", error);
            }
            
            // Either way, we don't throw—don't affect other handlers
        }
    }
    
    private isRetryable(error: Error): boolean {
        return error instanceof TemporaryFailureError ||
               error instanceof RateLimitError ||
               error instanceof TimeoutError;
    }
}

Bulkhead Pattern

Benefit 4: Enhanced Testability

Event-driven design dramatically improves testability at multiple levels:

Publisher Testing (Simple):

Handler Testing (Isolated):

Each handler can be tested in complete isolation. Give it an event, verify its behavior. The handler doesn't know or care about the publisher; it just processes events.

Integration Testing (Flexible):

testing-event-driven.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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
// ===== TESTING PUBLISHERS: Verify correct events are raised =====
 
describe("OrderService", () => {
    it("should publish OrderPlaced event when order is created", async () => {
        // Arrange: Simple mock dispatcher that captures events
        const capturedEvents: DomainEvent[] = [];
        const mockDispatcher: EventDispatcher = {
            dispatch: async (event) => { capturedEvents.push(event); },
        };
        
        const orderService = new OrderService(mockDispatcher, mockRepo);
        
        // Act: Place an order
        await orderService.placeOrder({
            customerId: "customer-123",
            items: [{ productId: "product-1", quantity: 2 }],
        });
        
        // Assert: Correct event was published
        expect(capturedEvents).toHaveLength(1);
        expect(capturedEvents[0].type).toBe("OrderPlaced");
        expect(capturedEvents[0].payload.customerId).toBe("customer-123");
        
        // We DON'T need to mock InventoryService, EmailService, etc.
        // because OrderService doesn't know about them!
    });
    
    it("should not publish event if order validation fails", async () => {
        const capturedEvents: DomainEvent[] = [];
        const mockDispatcher = { dispatch: async (e) => { capturedEvents.push(e); } };
        
        const orderService = new OrderService(mockDispatcher, mockRepo);
        
        // Act: Try to place invalid order
        await expect(
            orderService.placeOrder({ customerId: "", items: [] })
        ).rejects.toThrow(ValidationError);
        
        // Assert: No event was published
        expect(capturedEvents).toHaveLength(0);
    });
});
 
// ===== TESTING HANDLERS: Isolated, focused tests =====
 
describe("EmailHandler", () => {
    it("should send confirmation email when OrderPlaced event received", async () => {
        // Arrange: Mock only what this handler needs
        const mockEmailService = {
            sendOrderConfirmation: jest.fn().mockResolvedValue(undefined),
        };
        
        const handler = new EmailHandler(mockEmailService);
        
        // Create a test event—no need for full system
        const event: OrderPlacedEvent = {
            type: "OrderPlaced",
            occurredAt: new Date(),
            payload: {
                orderId: "order-123",
                customerId: "customer-456",
                customerEmail: "customer@example.com",
            },
        };
        
        // Act: Handle the event
        await handler.handle(event);
        
        // Assert: Email was sent with correct data
        expect(mockEmailService.sendOrderConfirmation).toHaveBeenCalledWith({
            email: "customer@example.com",
            orderId: "order-123",
        });
    });
    
    it("should not throw when email service fails", async () => {
        // Handler should be resilient—test that!
        const mockEmailService = {
            sendOrderConfirmation: jest.fn().mockRejectedValue(new Error("SMTP down")),
        };
        
        const handler = new EmailHandler(mockEmailService);
        
        // Act & Assert: No exception thrown
        await expect(handler.handle(testEvent)).resolves.not.toThrow();
    });
});
 
// ===== TESTING INTEGRATION: Selective handler registration =====
 
describe("Order Placement Integration", () => {
    it("should trigger inventory and email handlers", async () => {
        // Arrange: Create real dispatcher with selected handlers
        const dispatcher = new SynchronousEventDispatcher();
        
        const mockInventoryService = { reserve: jest.fn().mockResolvedValue(undefined) };
        const mockEmailService = { sendOrderConfirmation: jest.fn().mockResolvedValue(undefined) };
        
        dispatcher.subscribe("OrderPlaced", new InventoryHandler(mockInventoryService));
        dispatcher.subscribe("OrderPlaced", new EmailHandler(mockEmailService));
        // Note: NOT subscribing analytics, fraud, etc.—focused test
        
        const orderService = new OrderService(dispatcher, realOrderRepo);
        
        // Act
        await orderService.placeOrder(validOrder);
        
        // Assert: Both handlers were triggered
        expect(mockInventoryService.reserve).toHaveBeenCalled();
        expect(mockEmailService.sendOrderConfirmation).toHaveBeenCalled();
    });
});

Testing Advantages Summary

•Fewer mocks per test. Publishers only need EventDispatcher mocked. Handlers only need their direct dependencies.
•Isolated test failures. A broken handler test doesn't indicate broken publisher—they're separate.
•Easy to add test coverage. New handlers get their own test file—no modification to existing tests.
•Flexible integration testing. Wire up subsets of handlers to test specific flows.
•Event-based assertions. You can assert on what events were published, not just final state.
•Replay-friendly. Captured events can be replayed to test handler behavior.

Test Pyramid Alignment

Benefit 5: Separation of Concerns

Event-driven design naturally enforces separation of concerns—the principle that each component should have one reason to change and one responsibility to fulfill.

The Problem with Direct Calls:

In tightly coupled systems, the orchestrating component (like OrderService) accumulates concerns:

Primary business logic (creating orders)
Coordination logic (calling other services)
Error handling (what if inventory fails?)
Ordering logic (payment before inventory?)
Timeout handling (service too slow?)

The class becomes a "god object" that knows about everything.

The Event-Driven Solution:

With events, each component focuses on its core responsibility:

OrderService: Creating and validating orders
InventoryHandler: Reserving inventory
EmailHandler: Sending emails
Event Dispatcher: Routing events

No component needs to understand others' business logic. Each can be understood, modified, and tested in isolation.

separation-of-concerns.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
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
// ===== BEFORE: OrderService has too many concerns =====
 
class GodOrderService {
    // Constructor with too many dependencies
    constructor(
        private orderRepo: OrderRepository,
        private inventory: InventoryService,
        private payment: PaymentService,
        private email: EmailService,
        private analytics: AnalyticsService,
        private fraud: FraudService,
    ) {}
    
    async placeOrder(orderData: OrderData): Promise<Order> {
        // CONCERN 1: Order creation and validation
        const order = new Order(orderData);
        if (!order.isValid()) {
            throw new ValidationError(order.validationErrors);
        }
        
        // CONCERN 2: Fraud detection
        const fraudScore = await this.fraud.calculateRisk(order);
        if (fraudScore > 0.8) {
            throw new FraudSuspectedError(order.id);
        }
        
        // CONCERN 3: Inventory management
        try {
            await this.inventory.reserve(order.items);
        } catch (error) {
            if (error instanceof OutOfStockError) {
                // CONCERN 4: User notification
                await this.email.sendOutOfStockNotification(order.customerId);
                throw error;
            }
            throw error;
        }
        
        // CONCERN 5: Payment processing
        try {
            await this.payment.charge(order.customerId, order.total);
        } catch (error) {
            // CONCERN 6: Compensating actions
            await this.inventory.release(order.items);
            await this.email.sendPaymentFailedNotification(order.customerId);
            throw error;
        }
        
        // CONCERN 7: Persistence
        await this.orderRepo.save(order);
        
        // CONCERN 8: Notifications
        await this.email.sendOrderConfirmation(order);
        
        // CONCERN 9: Analytics
        await this.analytics.trackOrder(order);
        
        return order;
        
        // This method has NINE concerns. It will only grow.
        // Every new feature adds more complexity here.
    }
}
 
// ===== AFTER: Each component has ONE concern =====
 
// OrderService: ONLY order creation and validation
class FocusedOrderService {
    constructor(
        private orderRepo: OrderRepository,
        private eventDispatcher: EventDispatcher,
    ) {}
    
    async placeOrder(orderData: OrderData): Promise<Order> {
        // ONLY concern: Create and validate order
        const order = new Order(orderData);
        if (!order.isValid()) {
            throw new ValidationError(order.validationErrors);
        }
        
        await this.orderRepo.save(order);
        
        // Announce it happened. That's it.
        await this.eventDispatcher.dispatch({
            type: "OrderPlaced",
            payload: order.toEventPayload(),
        });
        
        return order;
    }
}
 
// FraudHandler: ONLY fraud detection
class FraudHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        const score = await this.fraudService.calculateRisk(event.payload);
        if (score > 0.8) {
            await this.eventDispatcher.dispatch({
                type: "OrderFlagged",
                payload: { orderId: event.payload.orderId, reason: "fraud_risk" },
            });
        }
    }
}
 
// InventoryHandler: ONLY inventory reservation
class InventoryHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        try {
            await this.inventoryService.reserve(event.payload.items);
        } catch (error) {
            await this.eventDispatcher.dispatch({
                type: "InventoryReservationFailed",
                payload: { orderId: event.payload.orderId, reason: error.message },
            });
        }
    }
}
 
// EmailHandler: ONLY email sending
class EmailHandler implements EventHandler<OrderPlacedEvent> {
    async handle(event: OrderPlacedEvent): Promise<void> {
        await this.emailService.sendOrderConfirmation(event.payload);
    }
}
 
// Each handler: single responsibility, single reason to change
// EmailHandler changes when email logic changes
// InventoryHandler changes when inventory logic changes
// They never need to know about each other

Single Responsibility at Scale

Benefit 6: Enabling Parallel Development

Event-driven design enables teams to work in parallel with minimal coordination. This is particularly valuable for larger organizations and complex projects.

The Coordination Problem:

In tightly coupled systems, adding a new feature often requires:

Modifying the central orchestrating component
Coordinating with the team that owns that component
Waiting for their review and merge
Potentially fixing integration conflicts

This creates bottlenecks and sequential development.

Event-Driven Parallelism:

With events, teams can work independently:

Team A publishes events from their domain
Team B creates handlers without touching Team A's code
Teams agree on event schemas (contracts)
Development proceeds in parallel

Development Workflow Comparison
Scenario	Tightly Coupled	Event-Driven
New team joins project	Must understand central orchestrator	Study relevant events; create handlers
New feature development	Modify shared component; coordinate merges	Create new handler in team's codebase
Bug in one handler	Might block releases of modified component	Fix in isolation; deploy independently
Different release cycles	All teams synchronized to shared component	Each handler released independently
Team A on vacation	Team B waits for code review	Team B creates handlers without Team A
Code ownership clarity	Shared component has unclear ownership	Each handler owned by one team

Event Contracts as API Boundaries:

In practice, events act as contracts between teams:

Producer teams define and document events they publish
Consumer teams subscribe to events they care about
The contract (event schema) is the only coordination point

As long as producers maintain backward compatibility of their events (adding optional fields rather than breaking changes), consumers can evolve independently.

This mirrors how APIs enable independent team development, but at a finer granularity—events are smaller, more focused contracts than full API surfaces.

Schema Evolution

Benefit 7: Natural Auditing and Debugging

Events create a natural audit trail. Every significant action is recorded as an event, providing insight into what happened, when, and in what order.

Built-in History:

When you persist events (even just to logs), you automatically have:

A record of every significant state change
Timestamps for when things happened
Data snapshots at each point in time
The sequence of operations

Debugging Benefits:

Reproduction: Capture the events that led to a bug; replay them in development.
Timeline reconstruction: See exactly what events occurred before an issue.
Root cause analysis: Trace which event triggered which handler.
Production investigation: Query event logs to understand customer issues.

event-auditing.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
85
86
87
// ===== Auditing Event Dispatcher =====
// Automatically logs all events for audit and debugging
 
class AuditingEventDispatcher implements EventDispatcher {
    constructor(
        private innerDispatcher: EventDispatcher,
        private eventStore: EventStore,
        private logger: Logger,
    ) {}
    
    async dispatch(event: DomainEvent): Promise<void> {
        // Record the event for audit trail
        await this.eventStore.append({
            ...event,
            recordedAt: new Date(),
            correlationId: this.getCurrentCorrelationId(),
        });
        
        // Log for immediate visibility
        this.logger.info(`Event published: ${event.type}`, {
            eventId: event.eventId,
            aggregateId: event.aggregateId,
            occurredAt: event.occurredAt,
        });
        
        // Dispatch to actual handlers
        await this.innerDispatcher.dispatch(event);
    }
}
 
// ===== Querying Event History =====
 
class EventQueryService {
    constructor(private eventStore: EventStore) {}
    
    // What happened to this order?
    async getOrderHistory(orderId: string): Promise<DomainEvent[]> {
        return this.eventStore.findByAggregateId(orderId);
        // Returns: [OrderPlaced, PaymentProcessed, InventoryReserved, OrderShipped, ...]
    }
    
    // What happened in the last hour?
    async getRecentEvents(eventType?: string): Promise<DomainEvent[]> {
        return this.eventStore.findRecent({
            since: new Date(Date.now() - 60 * 60 * 1000),
            type: eventType,
        });
    }
    
    // Reproduce a bug: get events leading up to failure
    async getEventsForDebugging(
        startTime: Date,
        endTime: Date,
        correlationId?: string
    ): Promise<DomainEvent[]> {
        return this.eventStore.findInTimeRange({
            start: startTime,
            end: endTime,
            correlationId,
        });
    }
}
 
// ===== Usage: Customer Support Investigation =====
 
async function investigateCustomerIssue(orderId: string) {
    const events = await eventQueryService.getOrderHistory(orderId);
    
    console.log(`Order ${orderId} timeline:`);
    for (const event of events) {
        console.log(`  ${event.occurredAt.toISOString()} - ${event.type}`);
        console.log(`    Payload: ${JSON.stringify(event.payload)}`);
    }
    
    // Output:
    // Order order-123 timeline:
    //   2024-01-15T10:30:45Z - OrderPlaced
    //     Payload: { customerId: "cust-456", items: [...], total: 99.99 }
    //   2024-01-15T10:30:46Z - PaymentProcessed
    //     Payload: { orderId: "order-123", transactionId: "tx-789", amount: 99.99 }
    //   2024-01-15T10:30:47Z - InventoryReserved
    //     Payload: { orderId: "order-123", items: [...] }
    //   2024-01-15T10:31:15Z - ShippingLabelCreated
    //     Payload: { orderId: "order-123", trackingNumber: "1Z999..." }
    //   2024-01-16T14:22:00Z - OrderDelivered
    //     Payload: { orderId: "order-123", deliveredAt: "2024-01-16T14:22:00Z" }
}

Event Sourcing Connection

The Trade-offs: What You Give Up

No architectural pattern is free. Event-driven design has real costs that must be weighed against its benefits.

Indirection and Complexity:

Following the code path is harder. You can't just "Go to Definition" from publisher to handler. You need to understand the subscription mechanism, search for handlers, and mentally trace the flow.

Real Trade-offs to Consider

•Harder to trace execution. Direct calls are explicit; event flows require searching for subscribers. New developers take longer to understand the system.
•Eventual consistency. If using async events, the system is eventually consistent. This adds complexity to UX and business logic.
•No return values. You can't get a response from an event. Complex workflows require multiple events or saga patterns.
•Ordering challenges. Handler execution order may be non-deterministic. If order matters, you need explicit sequencing.
•Debugging distributed flows. When handlers span services or processes, debugging requires distributed tracing infrastructure.
•Over-engineering risk. Not every interaction needs events. Simple direct calls are appropriate for cohesive operations.

Choose Wisely

Summary: Benefits of Event-Driven Approach

We've explored the concrete benefits of event-driven design. Let's consolidate:

Key Benefits Summary

•Loose coupling. Publishers don't know about subscribers. Components evolve independently.
•Extensibility. New behavior via new handlers—no modification to existing code.
•Resilience. Failure isolation, temporal decoupling, independent scaling.
•Testability. Fewer mocks, isolated tests, flexible integration testing.
•Separation of concerns. Each handler has one responsibility, one reason to change.
•Parallel development. Teams work independently, coordinating only on event schemas.
•Auditing and debugging. Events provide natural history and audit trails.

But remember the trade-offs:

Indirection makes code harder to trace
Eventual consistency adds complexity
No return values complicates some workflows
Over-engineering is a real risk

The key is applying event-driven design where its benefits outweigh its costs.

What's next:

Page Complete

3 / 4