Chain of Responsibility

Chain of Responsibility passes a request along a series of handlers until one of them deals with it. The sender does not know which handler will respond, and handlers do not know about each other.

You meet it constantly as middleware: every web framework's request pipeline, every logging framework's appender chain, every event system's bubbling. The pattern is more familiar than its name.

The problem

function handleRequest(req) {
  if (isBlockedIp(req))       return reject('blocked');
  if (!hasValidToken(req))    return reject('unauthenticated');
  if (!isAuthorised(req))     return reject('forbidden');
  if (exceedsRateLimit(req))  return reject('rate limited');
  if (!isValidPayload(req))   return reject('bad request');
  return route(req);
}

This works, and it fails in familiar ways: the list grows, adding a check edits a function that already works, no check can be reused or tested alone, and the set cannot be reordered or configured per route.

The pattern

Each check becomes a handler that either deals with the request or passes it on.

const pipeline = [blockList, authenticate, authorise, rateLimit, validate];

function handle(req) {
  for (const handler of pipeline) {
    const result = handler(req);
    if (result) return result;        // handled — stop
  }
  return route(req);                   // nobody objected
}

The classic formulation has each handler hold a reference to the next. A list with a loop, as above, is the same pattern with the linking extracted — easier to reorder, easier to inspect, and it does not bury the chain's shape inside the handlers.

Two shapes with different semantics

First-match wins. One handler deals with the request and the chain stops. Support-ticket escalation, exception handlers, routing.

Everyone runs, any may stop. Each handler processes and passes along, and any may terminate. This is middleware, and it differs in an important way: handlers can act on the way out as well as on the way in.

const withTiming = (next) => (req) => {
  const start = performance.now();
  const res = next(req);              // downstream runs here
  record(performance.now() - start);  // on the way back
  return res;
};

That two-phase shape is Decorator, and the resemblance is not coincidental — middleware is Chain of Responsibility and Decorator meeting in the middle. The distinction that survives: Chain of Responsibility contemplates a handler declining, Decorator does not.

The unhandled request

The pattern's defining hazard: what happens when nobody handles it?

The catalogue leaves this open, and implementations that leave it open produce the worst kind of bug — a request that silently does nothing, returns undefined, or falls through to a default that was never meant to be a catch-all. There is no error, no log line, and the symptom appears far away.

Three defensible policies, and you must choose one:

• A terminal handler that always handles, such as the router above. The chain cannot fall through because the last element is total.
• Explicit failure. Falling off the end throws, so an unhandled request is loud.
• A documented default, logged and counted, so "nothing handled this" is visible in metrics.

Silence is the only indefensible option.

Where it fits and where it does not

It fits when handlers are genuinely independent, when the set changes, when different contexts need different subsets — public routes skipping authentication, internal routes skipping rate limits — and when handlers should be individually testable.

It does not fit when the "handlers" are steps that all must run in a fixed order with no possibility of declining. That is a pipeline or a Template Method, and calling it a chain suggests an optionality that does not exist.

It also does not fit when handlers need each other's results. A handler that must know what an earlier one decided is not independent, and threading a shared mutable context through the chain to carry that information is how these designs become unreadable.

Check your understanding

Common mistakes

Undefined fall-through. A request nobody handles must fail loudly or hit a total terminal handler.

Treating order as arbitrary. Every adjacency encodes a decision, most visibly in security.

Handlers that depend on earlier handlers' annotations. Undeclared coupling that breaks silently on reorder or reuse.

A shared mutable context that grows. Once a dozen handlers annotate it, nobody can say what is present when.

Using it for steps that all must run. That is a pipeline, and calling it a chain implies an optionality that does not exist.

Handlers with side effects that fire before a later handler rejects. Logging a request as accepted before authorisation rejects it produces misleading data.

No way to see the chain. If the composition is assembled across several files, the effective order is unknowable.

Practice

Key takeaways

• Chain of Responsibility passes a request along handlers until one takes it — middleware is its most common form.
• Decide what happens when nobody handles it. A total terminal handler, an explicit throw, or a logged default; silence is indefensible.
• Two shapes: first-match wins, and everyone runs with any able to stop — the second allows work on the way out, which is where it meets Decorator.
• Order is part of the contract, especially for security: coarse limits before authentication, per-user limits after, validation after authorisation.
• Annotating a shared context creates undeclared dependencies. Keep annotations few, named, and traceable to their producer.
• Compose named stages so route-specific chains cannot omit the mandatory base, and make the effective order visible.
• If handlers all must run or need each other's results, it is a pipeline, not a chain.

Further reading

• Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1994).
• Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns (Addison-Wesley, 2003) — pipes and filters, and message routers.
• Frank Buschmann and others, Pattern-Oriented Software Architecture, Volume 1 (Wiley, 1996).
• Michael Nygard, Release It!, second edition (Pragmatic Bookshelf, 2018) — shedding load at the right layer.
• Martin Fowler, Patterns of Enterprise Application Architecture (Addison-Wesley, 2002) — intercepting filters.