Skip to main content
Design Patterns 80 XP · 9 min

Observer: The Subscription System

Let objects subscribe to events and be notified automatically — decouple event producers from consumers without either knowing about the other.

Showing
Ad (728×90)

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.

The problem

Bad

The solution

Good

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.

Done with this lesson?

Mark it complete to earn XP and track your progress.