Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
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.
In short
The decorator pattern is a way to add behavior to an object by wrapping it in another object that has the same interface. The caller cannot tell the difference, so you can stack small wrappers, like logging, retries and caching, instead of writing one subclass for every mix.
In short
The decorator pattern is a way to add behavior to an object by wrapping it in another object that has the same interface. The caller cannot tell the difference, so you can stack small wrappers, like logging, retries and caching, instead of writing one subclass for every mix.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Decorator Pattern across a run of lessons, not one page. These 4 alone are about 91 minutes of step-by-step reading, every one with a quiz.
Add responsibilities to objects dynamically by wrapping them, like middleware for your classes.
Retry failed operations intelligently, exponential backoff, jitter, and retry budgets.
Encapsulate requests as objects, enabling undo, queuing, logging, and distributed task execution.
Control access to an object by placing a surrogate in front of it, caching, security, and lazy loading in one pattern.
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 Decorator Patternpay once,
yours for life
The decorator pattern is one of the 23 design patterns in the Gang of Four book, from 1994. It is a structural pattern, which means it is about how objects are put together. The book describes it as a flexible alternative to subclassing for extending what an object does.
The idea is simple. You have an object that does one job. You want it to do a little more, such as write a log line on every call. You do not change the object. You build a second object, the decorator, that holds the first one and has the same methods. When someone calls the decorator, it does its extra work and then passes the call to the object inside. Passing the call on is called delegating.
Because the decorator has the same interface, the caller cannot see that anything changed. An interface here means the set of methods an object promises to have. You can wrap the decorator in another decorator, and that one in another. Each layer adds one behavior. You can see the whole family of patterns on the design patterns page.
The lesson starts with a stack many web developers have written. In Express, the Node.js web framework, you add middleware with app.use: CORS, then rate limiting, then an auth check, then logging. Each layer adds behavior around your route handler. You can add, remove or reorder a layer without changing the handler.
Java's input and output library is the classic example. A BufferedInputStream wraps a GZIPInputStream, which wraps a FileInputStream that reads data.gz. That puts buffering on top of decompression on top of file reading. Every layer is an InputStream. If you swap the file stream for a network stream, the buffering and decompression layers still work. This is what people mean by composition over inheritance: you combine small objects instead of building one deep class tree.
The lesson builds an HTTP client with two decorators. Here are the parts, using the names in the figure below:
Drawn from the lesson Decorator Pattern.
When the client calls send, the call goes in through Logging, then Retry, then the real client. The reply comes back out the same way. Each layer has one job. Each one can be removed without touching the others.
Suppose a UserService has four optional extras: logging, auth, caching and metrics. Each extra is either on or off. That gives 2 to the power of 4, or 16, combinations. With inheritance you would need a subclass for each mix you use, with names like LoggingCachingUserService. The class tree grows fast and becomes hard to change.
With decorators you write four small wrappers, one per extra. You pick the ones you need when you build the object, at runtime. Adding a fifth extra means writing one more wrapper, not doubling the number of classes.
Each wrapper also has a cost the lesson lists. A logging layer adds about 0.1 ms per call. A retry layer adds nothing on success and 200 to 1,600 ms when it retries. A cache layer returns in under a millisecond on a hit and skips every layer inside it.
The lesson calls this the single most important thing to understand. Each decorator wraps the next one. So the outer layer runs first, and it decides whether the inner layers run at all.
Take an auth check and a cache. If auth is the outer layer, written Auth(Cache(service)), every caller is checked before the cache is even asked. If the cache is the outer layer, written Cache(Auth(service)), the cache answers first. When its key does not include the user, a stored answer for one user can be handed to another user who never passed the auth check. The lesson notes that this security bug ships in production more often than you would expect.
The code below shows it. Both objects use the same three parts. Only the order differs. It was run with Node.js before it was added here.
decorator-order.js
// One interface: get(userId, key). Three small layers that all keep it.
const service = { get: (user, key) => `secret report for ${user}` };
const auth = (inner) => ({
get: (user, key) => (user === "admin" ? inner.get(user, key) : "403 Forbidden"),
});
const cache = (inner) => {
const store = new Map(); // the cache key ignores the user
return {
get: (user, key) => {
if (store.has(key)) return store.get(key);
const value = inner.get(user, key);
store.set(key, value);
return value;
},
};
};
const safe = auth(cache(service)); // auth is outer, so it runs first
const unsafe = cache(auth(service)); // cache is outer, so it runs first
safe.get("admin", "report");
unsafe.get("admin", "report");
console.log("safe: ", safe.get("guest", "report"));
console.log("unsafe:", unsafe.get("guest", "report"));Output (node, captured 2026-10-04)
safe: 403 Forbidden
unsafe: secret report for adminThe guest asked for the same key as the admin. In the unsafe order, the cache answered before auth could run. Because order decides behavior, write it down, and test it, wherever you build the stack.
All three patterns wrap an object, so they look alike in code. The lesson says the difference is intent: why are you wrapping this object?
In practice the lines blur. The lesson's own example is gRPC interceptors: they stack like decorators, but an auth interceptor also controls access like a proxy. The Proxy Pattern lesson covers the control side in depth. A close cousin is the chain of responsibility, where any handler may stop the request instead of passing it on.
Use decorators for cross-cutting concerns. These are jobs like logging, retries, caching and metrics that many classes need but none of them own. Use them when you want to add or remove behavior at runtime, and when the number of combinations would make subclasses impractical.
They have costs too. A deep stack is hard to debug: with seven layers you may step through seven delegate calls to find the bug. If the interface has many methods, every decorator must implement all of them, even just to pass them on. And because order matters, you need tests or documentation to keep it correct.
For the full lesson, including the retry sequence with a failed first attempt and a five-layer production stack with a circuit breaker, read the Decorator Pattern lesson next.
Java I/O streams
BufferedInputStream, GZIPInputStream and FileInputStream are all InputStreams, so each can wrap another. This is the textbook decorator stack.
Express middleware
app.use stacks CORS, rate limiting, auth and logging around a route handler. Each layer can be added or removed without changing the handler.
Python function decorators
The @ syntax wraps one function in another. It is a language feature for the same idea: add behavior around a call without editing the function.
A Python decorator, written with @, wraps a function in another function. You use it to add behavior around a call, such as timing, caching or an auth check, without editing the function itself. functools.lru_cache is a built-in example. It is a language feature, not the full object pattern, but the idea is the same: wrap, add one behavior, and pass the call on.
In C#, a decorator is a class that implements the same interface as the object it wraps and holds a reference to it. Each method does its extra work and then calls the same method on the inner object. .NET's own Stream classes work this way. A BufferedStream or a GZipStream wraps another Stream.
In C++ you define an abstract base class with virtual methods, which acts as the interface. The concrete object and each decorator derive from it. A decorator holds a pointer to another object of the base type, often a std::unique_ptr, and forwards calls to it after adding its own behavior. Because every layer has the base type, decorators can wrap each other in any order.
They are the patterns in the 1994 Gang of Four book, in three groups. Creational: Abstract Factory, Builder, Factory Method, Prototype, Singleton. Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy. Behavioral: Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor.
A decorator adds behavior and is made to be stacked, so every layer usually runs. A proxy controls access and usually stands alone in front of one object, deciding whether the real object is called at all. Both keep the same interface, so the difference is the reason you wrap.
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.
Proxy Pattern
A structural design pattern that puts a stand-in object with the same interface in front of a real object to control access to it, for example to cache, check permissions or load it lazily.
Adapter Pattern
A structural design pattern that wraps a class with an incompatible interface so it matches the interface your code expects, like a travel plug adapter for software.
Chain of Responsibility
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.
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 "Decorator Pattern" 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 Decorator Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.