Chain of Responsibility

Real-world analogy

An automated customer support phone line or corporate purchase approval ladder illustrates the Chain of Responsibility. When you dial technical support, you first reach an automated voice menu for basic password resets. If your issue is unresolved, your call escalates to a Tier 1 support technician. If the bug requires code inspection, the technician escalates the call to Tier 2 Engineering. Each level either resolves your issue or forwards your call to the next tier in the chain.

The problem

You are building an HTTP API gateway. Every incoming request must undergo a sequence of security and infrastructure checks before reaching the business controller:

1. IPRateLimiter: Block client if requests exceed 100 per minute.
2. AuthenticationFilter: Verify JWT signature and token expiration.
3. RoleAuthorizer: Check that the authenticated user possesses the ROLE_ADMIN scope.
4. PayloadSanitizer: Strip malicious <script> tags from input JSON.

Without the Chain of Responsibility, developers write a monolithic controller method filled with nested if-else blocks:

1 // Naive implementation: Monolithic nested conditional controller
2 class ApiGatewayController {
3   handleRequest(req) {
4     // 1. Rate limiting
5     if (this.isRateLimited(req.ip)) {
6       return { status: 429, error: "Too Many Requests" };
7     }
8     // 2. Authentication
9     if (!req.headers.authorization) {
10       return { status: 401, error: "Missing Auth Token" };
11     }
12     const user = this.verifyToken(req.headers.authorization);
13     if (!user) {
14       return { status: 403, error: "Invalid Token" };
15     }
16     // 3. Authorization
17     if (req.path.startsWith("/admin") && user.role !== "ADMIN") {
18       return { status: 403, error: "Unauthorized" };
19     }
20     // 4. Payload sanitization
21     req.body = this.sanitize(req.body);
22 
23     return { status: 200, data: "Order Created" };
24   }
25 }

1 public class Example {
2     static class ApiGatewayController {
3         // Monolithic: 5+ disparate concerns tangled in a single rigid method.
4         // Reordering checks, disabling checks in test environments, or adding
5         // new security layers requires modifying this brittle conditional tree.
6         public void handleRequest(String req) {
7             System.out.println("Processing monolithic nested checks...");
8         }
9     }
10 

This monolithic design violates the Single Responsibility Principle and the Open/Closed Principle. It is impossible to reorder checks, add a new cache handler, or bypass authentication in local development tests without editing the monolithic method.

The solution

The Chain of Responsibility pattern decouples the sender of a request from its receivers by giving multiple handlers a chance to process the request. Handlers are linked into a sequential chain, and the request travels down the chain until a handler either fulfills it or passes it to the next link.

• Handler (RequestHandler): Abstract class declaring the setNext() link and handle() contract.
• Concrete Handlers (RateLimiter, Authenticator, Authorizer): Inspects the request, processes it or forwards it to next.
• Client: Assembles the chain and dispatches the request to the head handler.

Step-by-step implementation

Step 1: Define the base handler abstraction

Establish the handler interface with a reference to the next handler in the pipeline.

Step 2: Implement concrete validation handlers

Each handler performs its specific check. If it fails, it halts and returns an error; otherwise, it calls super.handle(req).

Step 3: Assemble and execute the pipeline

The client configures the chain dynamically and passes incoming requests into the head.

1 const pipeline = new RateLimitHandler();
2 pipeline.setNext(new AuthTokenHandler());
3 
4 const res = pipeline.handle({ ip: "10.0.0.1", token: "valid_jwt_token" });
5 console.log(`Response: ${res.status} ${res.message ?? res.error}`);

1 public class Example

The complete example

Here is the complete, runnable implementation demonstrating a corporate expense approval chain (Stop Chain).

1 --- Request 1: Laptop Purchase ($800) ---
2 [Approved by Team Manager] Expense EXP-001 ($800) approved.
3 
4 --- Request 2: Server Cluster Hardware ($7,500) ---
5 [Escalating] Team Manager cannot approve $7500. Escalating to next tier...
6 [Approved by Director] Expense EXP-002 ($7500) approved.
7 
8 --- Request 3: Annual Enterprise Software License ($35,000) ---
9 [Escalating] Team Manager cannot approve $35000. Escalating to next tier...
10 [Escalating] Director cannot approve $35000. Escalating to next tier...
11 [Approved by Vice President] Expense EXP-003 ($35000) approved.
12 
13 --- Request 4: Corporate Jet Charter ($150,000) ---
14 

Variations

Stop chain vs pass-through middleware chain

1. Stop Chain (Pure GoF): Exactly one handler satisfies the request and terminates the chain execution immediately (e.g. corporate expense approvals, exception handler catch blocks).
2. Pass-Through / Interceptor Chain: Every handler in the chain performs work (authentication, CORS header injection, logging, telemetry), mutates or inspects the payload, and calls next() to invoke the remainder of the pipeline (e.g. Express middleware, Java Servlet Filters).

Express.js middleware and Java Servlet filters

Modern web servers organize request handling as a Chain of Responsibility:

• Express.js: (req, res, next) => { ... next(); }
• Java Servlet Filters: filterChain.doFilter(servletRequest, servletResponse)

Where you've already used it

• Java Servlet FilterChain: javax.servlet.Filter wraps HTTP requests with compression, security checks, and encoding conversions before reaching the target servlet.
• Spring Security SecurityFilterChain: Executes a sequence of 15+ security filters (CSRF filter, UsernamePasswordAuthenticationFilter, BearerTokenAuthenticationFilter).
• DOM Event Bubbling: In the browser, an event on a <button> travels up through parent <div>, <form>, <body>, and document nodes until a listener calls event.stopPropagation().
• Netty ChannelPipeline: Decodes incoming network bytes into frames, parses SSL/TLS, and extracts domain messages across linked pipeline handlers.

Pros and cons

When not to use it

Do not use Chain of Responsibility when all checks must execute regardless of failure and their execution order does not matter. If you just need a list of independent validators that all run to produce a combined list of validation errors, a simple loop over a list of validators is cleaner.

Related patterns

Interview questions

How does Chain of Responsibility differ from Decorator? Both rely on recursive delegation through a shared interface. However, Decorator executes all layers to enhance functionality, whereas classic Chain of Responsibility stops processing as soon as a single handler satisfies the request.

What happens if a request is not handled by any link in the chain? The request falls off the end unhandled. In production systems, you should always append a default fallback handler at the tail of the chain to log a warning, throw an exception, or return a 404/400 response.

How does DOM event bubbling illustrate Chain of Responsibility? When an event occurs on a deeply nested DOM element, the browser gives that element the first chance to handle it. If not stopped via event.stopPropagation(), the event travels up through ancestor container elements in a chain of responsibility.

Can a handler in a Chain of Responsibility mutate the request object before passing it to the next handler? Yes. In modern interceptor/middleware pipelines (like Express or Spring Web filters), handlers frequently mutate the request (e.g. decrypting bodies, attaching authenticated user identities, or parsing query strings).