Chain of Responsibility: Let the Request Find Its Own Handler

An engineer files a $7,500 expense for a laptop. Who signs off?

The naive answer lives in a method that grew one branch at a time: if (amount <= 1000) teamLead.approve(); else if (amount <= 10000) manager.approve(); else if (amount <= 50000) director.approve(); else escalateToVP(). Every re-org rewrites it. When finance inserts a new “budget owner” tier between manager and director, you edit the ladder, and you pray you got the boundary conditions right, because the branch you shifted also decides who approves refunds. The policy — who can authorise how much — is fused to the code that submits the request. The submitter shouldn’t know or care about the org chart. It just wants the expense approved by somebody with the authority.

The problem is coupling: the sender is hard-wired to a specific receiver. What you actually want is to hand the request to the first tier and let it travel up until someone with the authority stops it — the exact motion a real approval chain performs. The Gang of Four named it.

The intuition: customer support escalation tiers

Call a support line and you reach Tier 1. They can reset your password, resend an invoice, unblock your account — the routine 80%. Hit something they can’t resolve and they don’t say “I don’t know”; they escalate to Tier 2. Tier 2 handles the gnarlier 15% and escalates the rest to engineering. You, the caller, never dialed engineering directly. You dialed one number and your problem climbed the ladder on its own until it reached someone who could end it.

That’s the whole pattern. Each tier asks one question — can I handle this? — and if the answer is no, it forwards to the next tier without ever naming which tier that is. A bucket brigade works identically: each person either drops the bucket on the fire or passes it to the next pair of hands. Nobody in the line knows the whole line.

From here the members-only walkthrough builds the pattern end to end: the abstract Handler protocol and its next pointer diagrammed as a pipeline, the full Java/TypeScript code for both the pure expense chain and the pass-through middleware variant, a step-by-step trace of a request that stops mid-chain and one that falls off the end, the Decorator-vs-Chain distinction, the real-world chains you already depend on (Servlet filters, Express, Spring Security, Netty), the tradeoffs, and the interview corner.