creational
Chain of Responsibility
Pass a request along a chain of handlers. Each decides to process or pass to the next.
When a request might be handled by any of several processing steps — authenticate, rate-limit, validate, log, then finally do the work — hard-coding the sender to call each step in order couples it to the whole pipeline and makes reordering or inserting a step a code change in the wrong place. Chain of Responsibility decouples the sender from the receivers by stringing the handlers into a chain and letting the request flow along it.
Customer support escalation — Level 1 handles simple issues, escalates to Level 2, then engineering.
Key Concepts
1
Each handler holds a reference to the next handler and, on receiving a request, decides whether to process it, to pass it along by calling the next handler, or both. The sender simply hands the request to the head of the chain and never learns which handler ultimately dealt with it. Because the chain is assembled externally, you can add, remove, or reorder handlers — or build different chains for different contexts — without touching the handlers themselves or the sender. A handler can stop the chain early or let the request propagate to the end.
2
This is exactly how HTTP middleware pipelines work (auth then rate-limit then logging then the route handler), and it also models DOM event bubbling, logging frameworks that escalate by level, and multi-stage approval workflows. Two cautions: a request can fall off the end of the chain unhandled, so you usually want a default terminal handler or an explicit guarantee that something will catch it; and a long or misconfigured chain can be hard to trace, since the path a request takes is determined at assembly time rather than visible at the call site.