Skip to article frontmatterSkip to article content
Site not loading correctly?

This may be due to an incorrect BASE_URL configuration. See the MyST Documentation for reference.

Quick MCQ — Event routing

  • A) Observers cannot be removed once subscribed

  • B) Grouping observers by event type lets the publisher notify relevant listeners only

  • C) Event routing forces all observers to receive every event

Correct: B — event-type groups ensure only relevant observers are notified.

Exercises (Pyodide-ready)

  1. Implement FraudObserver that only prints a fraud warning when notified.

  2. Modify EventPublisher.notify so it also accepts wildcard subscriptions (e.g., '*' to receive all events).

  3. Add a small test that subscribes and unsubscribes an observer and asserts it no longer receives events (in notebook print-based form).

Observer Design Pattern

Notify many interested systems when one important event happens.

The Observer Pattern is ideal when one source of truth should broadcast events to many listeners without tightly coupling them together.

Business Framing

When an order is placed, multiple things may need to happen:

  • inventory should update

  • the customer should get a message

  • analytics should record the event

  • finance may log revenue

The order service should not hard-code every downstream action.

Visual Intuition

Core Idea

RoleResponsibility
Subject / PublisherTracks observers and sends updates
Observer / SubscriberReacts when notified
Event messageCarries business information

Worked Example: Order Notifications

Why not call all services directly?

Direct calls create tight coupling. The publisher should only know that observers can react to an event, not the internal details of each service.

Real-World Uses

  • event-driven dashboards

  • payment and fraud alerts

  • model-monitoring notifications

  • stock-level changes

  • workflow automation triggers

Benefits and Risks

BenefitRisk
Loose couplingHarder to trace event chains if overused
Easy to add subscribersNotification order may matter
Good for event-driven systemsForgotten subscriptions can cause bugs

Mini Quiz

  1. What does the publisher know about observers?

  2. Why is Observer useful in event-driven business systems?

  3. What operational risk appears if many observers accumulate with no discipline?

Answer Check

  1. Only that they support the expected update behavior

  2. One event can trigger many independent reactions cleanly

  3. Hard-to-debug notification chains and hidden side effects

Practice Prompt

Design a ModelTrainingPublisher that notifies:

  • an experiment tracker

  • a deployment checker

  • a Slack alert service

Design Hint

Treat “model trained” as the event and keep each follow-up action in its own observer so your training pipeline stays modular.

Interactive Code

What to notice

Observers can be attached or removed without rewriting the publisher. That flexibility is one reason event-driven systems often use this pattern.

Guided Practice

Which statement best captures the main benefit of Observer?

It guarantees that business rules never change Observer helps with event communication, not with freezing requirements.
One publisher can notify many listeners with low coupling That is the core collaboration model of Observer.
It chooses among interchangeable algorithms That describes Strategy.
It wraps objects with optional features That describes Decorator.

Exercises

  1. Add a FraudObserver that reacts only by logging a message.

  2. Extend the publisher so different event types can notify different groups of observers.

Exercise hint

Reuse the publisher-observer contract from the worked example: the publisher owns the list, and each observer only needs an update(event) method.

Key Takeaway

Observer helps you say: one event, many reactions, minimal coupling.

Programming for Machine Learning and Business
Strategy Design Pattern
Programming for Machine Learning and Business
Decorator Design Pattern