Problem: Multiple Handlers for a Request - Chain of Responsibility Pattern | OneNoughtOne

0/290

System Design LLDBehavioral Patterns (Part 2)

Chain of Responsibility Pattern

LevelIntermediate

Duration90 mins

TopicBehavioral Patterns (Part 2)

1 / 4

Problem: Multiple Handlers for a Request

When One Receiver Isn't Enough

Imagine you're building a customer support system for a large e-commerce platform. A customer submits a complaint about a defective product. This simple action triggers a remarkably complex routing challenge: who should handle this request?

The answer isn't straightforward. It might be a frontline support agent, a product specialist, a returns manager, a quality assurance team, or even an executive—depending on the complaint's severity, the product category, the customer's status, and a dozen other factors. The sender (the customer) shouldn't need to know the organizational structure. And critically, the handling logic shouldn't be hardcoded into a massive switch statement that requires modification every time the support hierarchy changes.

This is the fundamental problem the Chain of Responsibility pattern addresses: how do you route requests through a series of potential handlers without coupling the sender to specific receivers?

What You Will Learn

By the end of this page, you will understand the fundamental coupling problem that occurs when request senders must explicitly know about receivers. You'll explore scenarios where requests can be handled by multiple objects, identify the code smells that indicate the need for Chain of Responsibility, and understand why naive solutions lead to rigid, fragile architectures.

The Request Routing Dilemma

At its core, the Chain of Responsibility pattern addresses a pervasive software engineering challenge: how do we handle requests that can be processed by multiple objects when we don't know which object will handle them at compile time?

Consider the scope of this problem across different domains:

Request Routing Challenges Across Domains
Domain	Request Type	Potential Handlers	Challenge
Support Systems	Customer complaint	L1 Support, L2 Support, Manager, Executive	Escalation path depends on severity and customer tier
Event Processing	UI click event	Button, Panel, Window, Application	Event bubbles until consumed
Logging	Log message	Console, File, Network, Database loggers	Multiple handlers may process simultaneously
Authentication	Auth request	Token, OAuth, LDAP, Basic auth handlers	First matching strategy wins
HTTP Middleware	HTTP request	Auth, CORS, Logging, Caching, Routing layers	Sequential processing with optional short-circuit
Approval Workflows	Expense claim	Direct Manager, Department Head, Finance, CEO	Routing depends on claim amount and policy

The common thread:

In all these scenarios, we face the same structural problem:

A request originates from a sender
Multiple objects could potentially handle the request
The specific handler isn't known until runtime
The sender shouldn't need to know the handling structure

Without a principled approach, developers face a difficult choice: either tightly couple senders to receivers (destroying flexibility) or create massive conditional routing logic (destroying maintainability). Neither is acceptable in production systems.

The Naive Approach — Direct Coupling

Let's examine what happens when developers approach this problem without a principled pattern. We'll use a concrete example: an approval system for purchase orders where different approval levels are required based on the order amount.

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
// The naive approach: The sender explicitly routes to each handler
 
class PurchaseOrder {
    constructor(
        public readonly id: string,
        public readonly amount: number,
        public readonly requesterId: string,
        public readonly description: string
    ) {}
}
 
// Individual approval handlers
class SupervisorApproval {
    approve(order: PurchaseOrder): boolean {
        if (order.amount <= 1000) {
            console.log(`Supervisor approved order ${order.id} for $${order.amount}`);
            return true;
        }
        return false;
    }
}
 
class ManagerApproval {
    approve(order: PurchaseOrder): boolean {
        if (order.amount <= 10000) {
            console.log(`Manager approved order ${order.id} for $${order.amount}`);
            return true;
        }
        return false;
    }
}
 
class DirectorApproval {
    approve(order: PurchaseOrder): boolean {
        if (order.amount <= 100000) {
            console.log(`Director approved order ${order.id} for $${order.amount}`);
            return true;
        }
        return false;
    }
}
 
class CEOApproval {
    approve(order: PurchaseOrder): boolean {
        // CEO can approve any amount
        console.log(`CEO approved order ${order.id} for $${order.amount}`);
        return true;
    }
}
 
// The problematic client code
class PurchaseOrderProcessor {
    private supervisor = new SupervisorApproval();
    private manager = new ManagerApproval();
    private director = new DirectorApproval();
    private ceo = new CEOApproval();
 
    processOrder(order: PurchaseOrder): boolean {
        // Client must know the entire approval hierarchy
        if (this.supervisor.approve(order)) {
            return true;
        }
        if (this.manager.approve(order)) {
            return true;
        }
        if (this.director.approve(order)) {
            return true;
        }
        if (this.ceo.approve(order)) {
            return true;
        }
        return false;
    }
}

Critical Design Flaws

This code works, but it's deeply problematic. The PurchaseOrderProcessor is tightly coupled to every approval handler. It must know the complete chain, the correct order, and the approval logic. Any change to the hierarchy—adding a VP level, removing the supervisor, or changing the order—requires modifying the processor. This violates the Open/Closed Principle and creates a maintenance nightmare.

Let's analyze the violations systematically:

Design Principle Violations

•Open/Closed Principle Violation — Adding a new approval level requires modifying PurchaseOrderProcessor. The class is not closed for modification.
•Single Responsibility Violation — PurchaseOrderProcessor handles order processing AND knows the complete approval chain structure. These are separate concerns.
•Dependency Inversion Violation — High-level policy (order processing) depends on low-level details (specific approval classes). The dependencies point in the wrong direction.
•High Coupling — The processor is coupled to four concrete classes. Each class change potentially impacts the processor.
•Low Cohesion — The routing logic (which handler next) is mixed with processing logic (submitting the order). These should be separate responsibilities.

The Scaling Problem

The naive approach doesn't just violate design principles—it creates concrete maintenance problems that compound over time. Let's explore what happens as the system evolves:

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
// Six months later: We need regional approval for international orders
 
class PurchaseOrderProcessor {
    private supervisor = new SupervisorApproval();
    private manager = new ManagerApproval();
    private director = new DirectorApproval();
    private ceo = new CEOApproval();
    // New handler for regional approvals
    private regionalManager = new RegionalManagerApproval();
 
    processOrder(order: PurchaseOrder): boolean {
        // International orders need regional approval first
        if (order.isInternational) {
            if (!this.regionalManager.approve(order)) {
                return false;
            }
        }
 
        // Then the normal chain
        if (this.supervisor.approve(order)) {
            return true;
        }
        if (this.manager.approve(order)) {
            return true;
        }
        if (this.director.approve(order)) {
            return true;
        }
        if (this.ceo.approve(order)) {
            return true;
        }
        return false;
    }
}

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
// One year later: Regulatory compliance requires legal review for certain categories
 
class PurchaseOrderProcessor {
    private supervisor = new SupervisorApproval();
    private manager = new ManagerApproval();
    private director = new DirectorApproval();
    private ceo = new CEOApproval();
    private regionalManager = new RegionalManagerApproval();
    // New handlers for compliance
    private legalReview = new LegalReviewApproval();
    private complianceOfficer = new ComplianceOfficerApproval();
 
    processOrder(order: PurchaseOrder): boolean {
        // Compliance check for regulated categories
        if (order.category === 'PHARMACEUTICAL' || order.category === 'DEFENSE') {
            if (!this.complianceOfficer.approve(order)) {
                return false;
            }
        }
 
        // Legal review for large contracts
        if (order.amount > 50000 && order.type === 'CONTRACT') {
            if (!this.legalReview.approve(order)) {
                return false;
            }
        }
 
        // International orders need regional approval first
        if (order.isInternational) {
            if (!this.regionalManager.approve(order)) {
                return false;
            }
        }
 
        // Then the normal chain
        if (this.supervisor.approve(order)) {
            return true;
        }
        if (this.manager.approve(order)) {
            return true;
        }
        if (this.director.approve(order)) {
            return true;
        }
        if (this.ceo.approve(order)) {
            return true;
        }
        return false;
    }
}

The pattern is clear: every business requirement adds complexity to the processor.

Notice how the PurchaseOrderProcessor has become a tangled mess of conditional logic. This is the inevitable outcome of tight coupling—all complexity accumulates in the coordinating class.

Complexity Growth Over Time
Version	Handlers	Conditional Branches	Lines of Code	Maintenance Burden
Initial	4	4	~40	Low
Regional	5	6	~55	Moderate
Compliance	7	10	~80	High
2 more features	9+	15+	~120+	Very High

The Maintenance Nightmare

In production systems, this pattern leads to 'god classes' with thousands of lines of conditional routing logic. These become the most fragile, most frequently modified files in the codebase—the ones developers dread touching because any change might break something unexpected.

The Testing Problem

Tight coupling doesn't just hurt maintainability—it devastates testability. When the processor is coupled to concrete handler classes, testing becomes an exercise in frustration:

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
// Testing the naive approach is painful
 
describe('PurchaseOrderProcessor', () => {
    let processor: PurchaseOrderProcessor;
 
    beforeEach(() => {
        // We can't inject mocks—the processor creates its own handlers
        processor = new PurchaseOrderProcessor();
    });
 
    it('should route small orders to supervisor', () => {
        const order = new PurchaseOrder('1', 500, 'user1', 'Office supplies');
        
        // Problem 1: We can't verify which handler was actually called
        // Problem 2: Side effects from real handlers pollute tests
        // Problem 3: We're testing 4+ classes simultaneously
        const result = processor.processOrder(order);
        
        expect(result).toBe(true);
        // But did the supervisor handle it? We can't easily verify.
    });
 
    it('should escalate to manager for medium orders', () => {
        const order = new PurchaseOrder('2', 5000, 'user1', 'Equipment');
        
        // Problem 4: Test depends on supervisor's implementation rejecting first
        // Problem 5: If supervisor's threshold changes, this test might break
        const result = processor.processOrder(order);
        
        expect(result).toBe(true);
        // No way to verify the routing path without extensive setup
    });
 
    it('should handle compliance requirements', () => {
        // Problem 6: Testing one feature (compliance) requires 
        // setting up all handlers, even unrelated ones
        const order = new PurchaseOrder('3', 60000, 'user1', 'Pharmaceuticals');
        order.category = 'PHARMACEUTICAL';
        order.type = 'CONTRACT';
        
        // This tests compliance, legal, AND normal approval chain
        // What exactly are we testing? Everything, which means nothing focused.
        const result = processor.processOrder(order);
    });
});

Testing Anti-Patterns Introduced

•No isolation — Tests exercise multiple classes simultaneously. A bug in any handler can fail tests for all features.
•Untestable routing — The routing logic is embedded in the processor. We can't verify which path a request took without adding explicit logging.
•Brittle tests — Tests depend on the internal order of handlers. Reordering the chain breaks tests even if behavior is preserved.
•Coverage gaps — Edge cases in routing logic are hard to cover because they require specific combinations of handler states.
•Slow tests — Real handlers may have dependencies (databases, APIs). Without mocking, tests become integration tests.
•Impossible unit testing — By definition, we cannot unit test the processor because it instantiates its own dependencies.

The fundamental issue:

Unit testing requires the ability to isolate the unit under test. When a class instantiates its own collaborators, isolation becomes impossible. The processor cannot be tested in isolation from the handlers, and the handlers cannot be mocked because they're created internally.

This is a violation of the Dependency Inversion Principle manifesting as a testing problem. High-level modules (the processor) should not depend on low-level modules (concrete handlers). Both should depend on abstractions.

The Real-World Manifestation

The coupling problem isn't hypothetical—it manifests in production systems across industries. Here are patterns that experienced engineers recognize immediately:

Code Smell Indicators

•Giant switch/if-else chains — Request routing via conditional logic that spans hundreds of lines
•Frequent file modifications — The routing class changes with almost every feature
•Circular dependencies — Handlers knowing about other handlers to 'forward' requests manually
•Copy-paste routing logic — Similar conditionals duplicated across multiple entry points
•Magic strings/numbers — Handler selection based on hardcoded identifiers

Operational Symptoms

•Feature velocity slowdown — Adding new handlers takes longer and longer
•Regression frequency — Changes to routing break unrelated features
•Testing gaps — Critical routing paths have low test coverage because they're too complex to test
•Deployment fear — Teams avoid touching routing logic because 'it works'
•Documentation rot — The actual routing behavior diverges from documented behavior

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
// This pattern exists in countless production systems
 
function routeRequest(request: Request): Response {
    // 400+ lines of this pattern
    if (request.type === 'AUTH' && request.method === 'LOGIN') {
        return authHandler.handleLogin(request);
    } else if (request.type === 'AUTH' && request.method === 'LOGOUT') {
        return authHandler.handleLogout(request);
    } else if (request.type === 'USER' && request.action === 'CREATE') {
        if (request.source === 'ADMIN') {
            return adminUserHandler.create(request);
        } else if (request.source === 'SELF_SERVICE') {
            return selfServiceHandler.create(request);
        } else if (request.source === 'BULK_IMPORT') {
            return bulkHandler.create(request);
        }
    } else if (request.type === 'ORDER') {
        // Different routing based on order state
        if (request.order.status === 'PENDING') {
            if (request.order.amount < 1000) {
                return supervisorHandler.process(request);
            } else if (request.order.amount < 10000) {
                return managerHandler.process(request);
            } // ... and on and on
        }
    }
    // ... 350 more lines of similar logic
    
    throw new Error('Unknown request type');
}

The 'God Router' Anti-Pattern

This code pattern is so common it deserves a name: the 'God Router.' It's a single function or class that knows about every handler, every routing condition, and every business rule. It's the choke point through which all changes must flow, making it the most fragile and feared component in the system. The Chain of Responsibility pattern exists specifically to prevent this.

Business Impact of the Coupling Problem

Coupling problems aren't just technical concerns—they translate directly to business costs. Let's quantify the impact:

Business Cost of Tight Coupling in Request Routing
Impact Category	Technical Cause	Business Consequence
Development Velocity	Every new handler requires modifying the router	Features that should take 2 days take 2 weeks due to integration complexity
Deployment Risk	The router is a single point of failure	Deployments require extensive regression testing; emergency fixes are risky
Team Scalability	Multiple teams can't work on handlers independently	Teams block each other; merge conflicts are constant
Onboarding Time	New developers must understand the entire routing structure	Longer ramp-up time; new hires can't contribute to routing for months
Testing Costs	Integration tests required for every change	Slow CI/CD pipelines; reduced test confidence
Incident Response	Difficult to isolate routing bugs	Longer MTTR; cascading failures from routing errors

A concrete example:

Consider an e-commerce platform that processes 10,000 orders per day through an approval workflow. The approval router is a 2,000-line function with 50+ conditional branches.

Adding a new approval tier for a new product category requires modifying the router
Four developers touch this file in any given week, causing merge conflicts
The test suite for this component takes 45 minutes to run due to integration dependencies
The last three production incidents involved incorrect routing after changes

The cumulative cost: an estimated 20% of engineering time spent managing the complexity of this single component. For a team of 10 engineers, that's effectively 2 full-time engineers doing nothing but fighting the router.

The Strategic Perspective

This isn't about code aesthetics—it's about engineering economics. Poor coupling in request routing creates an ongoing tax on the entire development organization. The Chain of Responsibility pattern, properly applied, eliminates this tax by making handlers independently deployable, testable, and modifiable.

Formal Problem Statement

Having explored the problem through examples and analysis, let's formalize what we're solving. The Chain of Responsibility pattern addresses a specific structural problem with well-defined characteristics:

The Problem Definition

Given: A request that can be handled by multiple objects, where the specific handler is not known until runtime.

Constraint: The sender should not be coupled to specific receivers.

Objective: Create a structure where requests are routed to appropriate handlers without the sender knowing the handling structure, while allowing the handler set and order to change dynamically.

The problem has several key characteristics:

Problem Characteristics

•Multiple potential handlers — More than one object can process the request. The request doesn't belong to a single handler.
•Runtime handler determination — The appropriate handler depends on request properties, system state, or other runtime factors.
•Handler ordering matters — Handlers may need to process in a specific sequence, or the first capable handler should respond.
•Handler independence desired — Each handler should be modifiable without affecting others.
•Dynamic chain composition — The set of handlers or their order may need to change after compile time.
•Sender-receiver decoupling — The request sender should not know which specific object handles its request.

What we need:

A design that provides:

Loose coupling between request senders and handlers
Handler extensibility without modifying existing code
Composable chains that can be configured at runtime
Single responsibility for each handler
Testability through isolation and injection

This is precisely what the Chain of Responsibility pattern delivers, which we'll explore in the next page.

Summary: The Problem We're Solving

We've thoroughly examined the problem that the Chain of Responsibility pattern addresses. Let's consolidate our understanding:

Key Takeaways

•Request routing is complex — When multiple objects can handle a request, routing logic must determine the appropriate handler at runtime.
•Naive solutions create tight coupling — Direct routing couples senders to all potential receivers, violating Open/Closed, SRP, and DIP.
•Coupling compounds over time — Each new handler or routing rule adds to the central router's complexity, creating maintenance nightmares.
•Testing becomes impossible — Coupled routers can't be unit tested; they require full integration testing for every change.
•Business costs are real — Slower velocity, higher risk, and team coordination problems directly impact the bottom line.
•The pattern provides structure — Chain of Responsibility offers a principled solution that addresses all these concerns.

What's next:

Now that we understand the problem in depth, we're ready to explore the solution. The next page introduces the Chain of Responsibility pattern itself—how chaining handler objects provides the decoupling, flexibility, and maintainability we need.

Page Complete

You now understand why direct coupling between request senders and handlers creates fundamental design problems. You've seen how these problems manifest in real code, impact testing, and create business costs. With this foundation, you're prepared to see how the Chain of Responsibility pattern elegantly solves these challenges.