Observer: The Subscription System
Let objects subscribe to events and be notified automatically — decouple event producers from consumers without either knowing about the other.
Why this matters
When you place an order, the system must send a confirmation email, reserve inventory, and record an analytics event. The naive approach puts all three calls inside place_order(). Adding a fourth reaction — say, a Slack notification — requires editing the order service. The Observer pattern inverts this: the order service emits one event, and any number of subscribers react independently. The service stays stable while capabilities grow by subscription.
Real-world forms
Browser DOM events, Node.js EventEmitter, domain events in DDD, message brokers (RabbitMQ, Kafka), and reactive streams (RxJS, Python's asyncio subjects) are all Observer at heart. The pattern scales from in-process callbacks to distributed event buses — the core idea stays the same: producers and consumers share only a contract (the event type), not an implementation.
💡Key takeaway
When one event triggers multiple unrelated reactions, Observer prevents the source from knowing all its consequences — new reactions are added as new subscribers, never as edits to the source.
🔧 Some exercises may still have errors. If something seems wrong, use the Feedback button (bottom-right of the page) to report it — it helps us fix it fast.
Hint: When one event triggers multiple unrelated reactions, Observer prevents the source from knowing all its consequences.
✗ Your version