Loading...
System Design and AI Engineering, by Roni Das. 974 interactive lessons.
Start LearningIntermediate · Microservices Architecture
A behavioral design pattern where an object keeps a list of subscribers and notifies each one when its state changes, so the object does not need to know what the subscribers do.
In short
The observer pattern is a behavioral design pattern where one object, the subject, keeps a list of observers and notifies each of them when its state changes. The subject does not need to know what any observer does with the news.
In short
The observer pattern is a behavioral design pattern where one object, the subject, keeps a list of observers and notifies each of them when its state changes. The subject does not need to know what any observer does with the news.
This page is the free part.
₹499 in India$49 everywhere elseonce, for the whole course
The System Design course covers Observer Pattern across a run of lessons, not one page. These 4 alone are about 74 minutes of step-by-step reading, every one with a quiz.
Let objects subscribe to events and react when something changes, the foundation of event-driven systems.
The mediator pattern sends all communication through one central coordinator. Compares mediator, observer and event bus, and the god object risk.
Encapsulate requests as objects, enabling undo, queuing, logging, and distributed task execution.
Attaching permission lists directly to resources, who can do what to this specific object.
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 Observer Patternpay once,
yours for life
The lesson starts with an online shop. A customer places an order. Now the system must send a confirmation email, update the stock count, tell the warehouse to pack, log the event for analytics and add loyalty points. The easy first version puts all five actions inside placeOrder().
Then marketing wants an abandoned cart campaign. Finance wants live revenue numbers. The fraud team wants to check purchases. Soon placeOrder() is 200 lines long and knows about every team in the company. It changes every week, because someone always needs one more reaction to "an order was placed".
The Observer pattern turns this around. placeOrder() just announces that an order was placed. Every interested service has signed up to hear that. Each one reacts on its own, and the order code does not change when a new one joins.
Observer is one of the 23 patterns in the 1994 Gang of Four book, in the behavioral group. Its intent is to define a one-to-many dependency between objects, so that when one object changes state, all its dependents are notified and updated automatically. People also call it the observer model, or publish and subscribe at small scale.
Each role has a clear job.
Drawn from the lesson Observer Pattern.
The subject keeps a list of observers. It has a method to add one, subscribe(), and a method to remove one, unsubscribe(). When its state changes, it walks the list and calls update() on each observer.
Here is the part that is often misread, including on one slide of the lesson. The subject does know its observers, because it holds references to them in its list. What it does not know is their concrete class or what they do. It only knows they have an update() method. The lesson's own comparison slide states this correctly: in Observer, the subject holds a list of observer references. When publisher and subscriber truly never see each other, with a broker in between, that is pub/sub, covered below.
The lesson walks through a full lifecycle. At startup, services subscribe. When an order is placed, the subject walks its list and notifies each observer. When a service shuts down for a deploy, it unsubscribes, so the subject stops calling it. The code below does exactly that. It was run with Node.js before it was added here.
order-observer.js
// Subject: keeps a list of observers and notifies each one when an order is placed.
class OrderService {
constructor() { this.observers = []; }
subscribe(observer) { this.observers.push(observer); }
unsubscribe(observer) { this.observers = this.observers.filter((o) => o !== observer); }
placeOrder(order) {
console.log(`order ${order.orderId} placed`);
for (const o of this.observers) o.update("OrderPlaced", order); // one loop, no knowledge of what each does
}
}
// Observers: each one implements the same update() method.
const emailObserver = { update: (e, o) => console.log(` email: confirmation for ${o.orderId}`) };
const inventoryObserver = { update: (e, o) => console.log(` inventory: reserve stock for ${o.orderId}`) };
const analyticsObserver = { update: (e, o) => console.log(` analytics: record ${e}, total ${o.total}`) };
const orders = new OrderService();
orders.subscribe(emailObserver);
orders.subscribe(inventoryObserver);
orders.subscribe(analyticsObserver);
orders.placeOrder({ orderId: "A-1001", total: 499 });
// The email service shuts down for a deploy, so it unsubscribes.
orders.unsubscribe(emailObserver);
orders.placeOrder({ orderId: "A-1002", total: 999 });Output, captured 2026-10-04 (node order-observer.js)
order A-1001 placed
email: confirmation for A-1001
inventory: reserve stock for A-1001
analytics: record OrderPlaced, total 499
order A-1002 placed
inventory: reserve stock for A-1002
analytics: record OrderPlaced, total 999Two details in the output matter. First, the observers ran one after another, inside placeOrder(). That is synchronous delivery: if one observer is slow, the whole call is slow. Second, after the unsubscribe, the email observer is no longer called. Adding a fraud observer later would be one more subscribe() line. The OrderService class would not change.
The strengths are real. New reactions do not touch the subject, which is the open/closed principle in action: open for extension, closed for modification. Observers can join and leave at runtime. And the lesson notes that Observer at small scale is what message queues such as Kafka and RabbitMQ do at large scale.
The lesson is just as clear about the costs.
One more cost comes from the code above. If notify is synchronous and one observer is slow or throws, it hurts the subject. The lesson's advice is to fan out asynchronously, or hand the event to a queue and let each consumer pull it.
These three get mixed up in interviews all the time. The lesson's comparison slide separates them on four points.
The lesson's rule: the move from Observer to pub/sub happens when your system crosses process boundaries. You start with subject.notify() in one codebase. When the observers become separate services, you put Kafka or SNS in the middle and publish events instead of calling methods. The idea is the same. The transport changes. The Pub/Sub Pattern lesson covers that side, and event-driven architecture is the system-wide version.
Observer is also easy to confuse with two siblings. A Command is a request stored to run later. A Strategy is an algorithm swapped in and called at once. An observer is a callback that the subject fires when it decides to. See design patterns for the full set.
The best next step is the Observer Pattern lesson. It shows the notify swimlane for four services, the subscribe and unsubscribe sequence, and ends with a short quiz.
Browser DOM events
addEventListener registers an observer on an element. The lesson lists DOM listeners as the pattern in everyday use.
Node.js EventEmitter
Listeners registered by event name are called synchronously, in registration order, when emit() runs.
Java Swing and Spring
The lesson's examples of classic Observer: Swing listeners and Spring ApplicationEvent.
Redux and React
Redux store subscriptions notify listeners after each change. The lesson calls React's useState and useEffect observer-like.
Webhooks
A service calls a URL you registered when something happens: the observer idea across the network.
It is a behavioral design pattern with a one-to-many link. One object, the subject, keeps a list of observers. When its state changes, it calls an update method on each observer in the list. New observers can subscribe without any change to the subject's code.
Browser DOM event listeners, Node.js EventEmitter, Redux store subscriptions, Java Swing listeners and Spring application events all follow it. Across services, webhooks and Kafka consumers apply the same idea, with a network or a broker in between. A YouTube channel notifying its subscribers about a new video is the everyday version.
You declare an observer interface with an update method, and the subject keeps a List of those observers. Java once shipped java.util.Observer and java.util.Observable, but both were deprecated in Java 9. The Java docs say the model was limited and the order of notifications was unspecified. They point to java.beans, java.util.concurrent or the Flow API instead.
The structure is the same. An abstract Observer class declares a virtual update() function. The subject keeps a container of observer pointers, with attach and detach methods, and loops over it to notify. Detach observers before they are destroyed, or the subject will call a dangling pointer.
In Observer, the subject holds direct references to its observers and calls them, usually synchronously, in one process. In pub/sub, a broker sits between publishers and subscribers, who never see each other, and delivery is asynchronous and often durable.
Checked against these on .
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.
Pub/Sub
A messaging pattern where publishers send messages to topics, and subscribers receive messages from topics they care about. Publishers don't know who's listening.
Event-Driven Architecture
A design pattern where services communicate by producing and consuming events rather than making direct calls. Promotes loose coupling and asynchronous processing.
Webhook
An HTTP callback triggered by an event. Instead of polling for updates, the source system pushes a notification to your URL when something happens.
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 "Observer 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 Observer Pattern lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.