Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A behavioral design pattern that passes a request along a chain of handlers, where each handler either deals with it or passes it to the next one. HTTP middleware is the everyday example.
In short
The chain of responsibility pattern passes a request along a line of handlers, and each handler either deals with it or passes it to the next one. The sender does not know which handler will act. HTTP middleware, such as Express's next(), is the everyday example.
In short
The chain of responsibility pattern passes a request along a line of handlers, and each handler either deals with it or passes it to the next one. The sender does not know which handler will act. HTTP middleware, such as Express's next(), is the everyday example.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Chain of Responsibility across a run of lessons, not one page. These 4 alone are about 85 minutes of step-by-step reading, every one with a quiz.
Pass requests along a chain of handlers, each handler decides to process it or pass it on.
Add responsibilities to objects dynamically by wrapping them, like middleware for your classes.
Guarantee that your database write and message publish either both happen or neither does.
The next generation of HTTP, built on UDP with QUIC for zero round-trip connections and true multiplexing.
all part of
System Design Masterclass
770 lessons · about 283 hours · 18 free to read
₹499in India, by UPI
$49everywhere else, by PayPal
Ive started this course by accident - LLM advised me this site. When I passed few free lessons, I had no doubt - this course should be bought. And I did it with special pleasent price and it was best decision of the month. Content is great, interesting to read and with a lot of practial cases (what makes it different from other souces and books) I hope to teach all the lessons, that will be my supergoal. Glad that I found this resource and speacial Thank You to Roni Das - Great Job!
You own this course
Continue with Chain of Responsibilitypay once,
yours for life
The chain of responsibility is one of the 23 design patterns in the Gang of Four book, from 1994. It is a behavioral pattern, which means it is about how objects share work and talk to each other. Its goal is to separate the sender of a request from the object that finally handles it. It does this by giving more than one object a chance to handle the request.
The objects that can act are called handlers. They are linked in an ordered line, the chain. A request enters at the first handler. That handler looks at it and decides. If it can deal with the request, it does. If not, it passes the request to the next handler. If no handler deals with it, a default action runs, or an error is returned.
The lesson opens with a phone call to a bank. An automated menu tries first. If it cannot help, a Level 1 agent takes the call. Then Level 2. For a really hard case, a manager. Each level gets a turn, nobody skips a level, and the call stops at the first level that can solve it. For the wider family of patterns, see design patterns.
The lesson's main example is an HTTP request, POST /api/orders, going through Express middleware. Middleware is code that runs between the moment a request arrives and the moment your route code handles it. Each handler gets the request and a function called next. Calling next() hands the request to the next handler. Sending a response instead ends the chain.
Drawn from the lesson Chain of Responsibility.
Notice what each handler knows. The sender only knows the first handler. Each handler only knows that there is a next one. None of them knows the full list. That is why you can add a new handler, such as a logger, without editing the others.
The Express docs state the rule plainly. A middleware function must either end the request and response cycle or call next(). If it does neither, the request is left hanging.
The lesson names the key design decision. Does handling the request stop the chain, or does every handler get a turn? The answer gives two variants.
Real systems often mix both. In the lesson's Express chain, auth and rate limiting can stop the request, while logging always passes it on. Kubernetes admission control is another case. Mutating controllers run first and may change the object. Validating controllers run after them. If any controller in either phase rejects the request, the whole request is rejected at once.
Java servlet filters follow the same idea. Each filter does its work and calls chain.doFilter() to pass the request along, or skips that call to stop it.
These three are close cousins and often confused. The lesson separates them like this.
A short rule from the lesson: when you hear middleware pipeline, think chain of responsibility with optional stopping. When you hear decorator stack, think every layer runs.
The same idea appears at the edge of a system. An API gateway often runs an authorizer, a request validator and a rate limiter before the request reaches your function. The command pattern, the lesson that comes before this one, is useful here too, because a request wrapped as an object is easy to pass along a chain.
Use a chain when the sender should not know which object will handle a request. Use it when several objects might handle it and the right one is only known at runtime. And use it when you want to build processing steps that you can add or remove without changing existing code.
Do not use it when you already know which handler should take the request. A direct call is simpler and faster than walking a long chain.
Watch the length of the chain. In a large Express app with 20 or more middleware functions, the question "which of these handlers ate my request?" is a real debugging problem. Logging when each handler stops the chain makes that much easier.
Watch hidden order rules too. If handler 7 needs data that handler 3 sets, that is a contract nobody wrote down. It breaks the day someone reorders the chain. Keep such rules few, and test the order.
To go further, the Chain of Responsibility lesson walks through the handler decision flowchart step by step and ends with a short quiz.
Express
Each middleware function receives next. It either ends the response or calls next() to pass control on; doing neither leaves the request hanging.
Kubernetes admission control
Mutating admission controllers run first, then validating ones. A rejection by any controller in either phase rejects the request immediately.
Browser DOM events
A click bubbles from the target element up through its parents, and any listener can stop it with stopPropagation().
Java servlet filters
Each filter processes the request and calls chain.doFilter() to pass it to the next filter or the servlet.
In C#, you define a Handler base class or interface with a method such as Handle(request) and a reference to the next handler. Each concrete handler checks whether it can deal with the request. If it can, it does. If not, it calls next.Handle(request). ASP.NET Core middleware is the built-in example: each piece receives the next delegate and decides whether to call it.
The Gang of Four book sorts its 23 patterns into three types. Creational patterns are about how objects are created, such as Factory Method and Singleton. Structural patterns are about how objects are put together, such as Adapter, Decorator and Proxy. Behavioral patterns are about how objects share work, such as Chain of Responsibility, Command, Observer and Strategy.
Express middleware is an example of the chain of responsibility. An auth handler checks the token and calls next(), a rate limiter checks the quota and calls next(), and a validator checks the body. Any one of them can send an error and stop the request. Java's BufferedInputStream wrapped around a FileInputStream is an example of the decorator pattern.
In a plain list of calls, the caller decides everything and calls each function in turn. In a chain, each handler decides by itself whether to handle the request or pass it on. The sender does not know which handler will act, so handlers can be added or removed without changing the sender.
Design Patterns
Named, reusable solutions to problems that keep coming up in object-oriented code, such as creating objects, wrapping interfaces or reacting to events. The classic catalogue of 23 was published by the Gang of Four in 1994.
Decorator Pattern
A structural design pattern that wraps an object in another object with the same interface to add behavior, such as logging, caching or retries, without changing the original class.
Command Pattern
A behavioral design pattern that turns a request into an object holding everything needed to run it, so requests can be queued, logged, retried or undone.
API Gateway
A single entry point for all client requests that routes them to the appropriate microservice. Handles auth, rate limiting, and request transformation.
Microservices
An architecture where an application is split into small, independent services that communicate over the network. Each service owns its own data and can be deployed separately.
Monolith
A single, unified application where all features share the same codebase and deployment. Simpler to start with but harder to scale individual parts.
This page explains the idea. The "Chain of Responsibility" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the Chain of Responsibility lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.