We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design Masterclass · Microservices Architecture
Free preview: the first 2 parts of this 7-part lesson.
Already bought the course? Sign in to read the whole lesson.
this lesson is part of
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design courseread the rest of this lesson in
System Design Masterclass
Unlock this lesson and the 751 other paid lessons
$25 once, by PayPal
See the System Design coursein Microservices Architecture
This lesson is part of the full System Design Masterclass. Unlock it along with 769 other lessons for a one-time payment.
One-time payment by card or PayPal
Get Lifetime AccessOne-time payment: UPI, card or netbanking
Get Lifetime Access18 Foundation lessons are free, no payment needed. Try them now
It is easy and good
“It is really nice and good Please join the course”
You call your bank's customer support. The automated system tries to handle your request first. "Press 1 for account balance." If it cannot help, you get transferred to a Level 1 agent. If they cannot help, you get escalated to Level 2. If it is really complicated, a manager takes over.
Each level in this chain has a shot at handling your request. If they can, great, the chain stops. If they cannot, they pass it to the next handler in line. Nobody skips levels. Nobody handles something they are not qualified for.
That is the Chain of Responsibility pattern. You build a pipeline of handlers, each with a specific capability. A request enters the chain and flows through until something handles it, or it falls off the end.
Express middleware is exactly this. Your auth middleware checks credentials. If the token is invalid, it sends a 401 and the chain stops. If valid, it calls next(). checks quotas. Under the limit? next(). Over? 429 and stop. Validator checks the request body. Valid? next(). Invalid? 400 and stop. The request flows through the chain until a handler either resolves it or passes it along.
AWS works the same way. An incoming request passes through an authorizer, then a request validator, then a mapping template, then a rate limiter, then finally reaches your Lambda function. Each stage either passes or rejects.
The Chain of Responsibility decouples the sender of a request from its receiver by giving multiple objects a chance to handle the request.
| Aspect | Details |
|---|---|
| The Chain | An ordered sequence of handler objects |
| Each Handler | Can process the request OR pass it to the next handler |
| The Sender | Does not know (or care) which handler processes the request |
| The End | If no handler processes it, a default action occurs (or error) |
There are two important variants:
Short-circuit chain: The first handler that can process the request does so, and the chain stops. Exception handling works this way. A try/catch block catches the first matching exception type. DOM event bubbling works this way too: click the button, the event bubbles up to the div, the body, the document. The first handler that calls stopPropagation() ends the chain.
Pipeline chain: Every handler processes the request and passes it on. Express middleware in "pipeline mode" works this way. A logging middleware logs the request and always calls next(). A correlation-ID middleware attaches a request ID and always calls next(). Every handler touches the request, none stop it.
The key design decision: does handling the request stop the chain, or does every handler get a turn?