Observer and Mediator: A One-Page Decision Note

Choose by dependency

Design question	Observer-style notification	Mediator-style coordination
What is the relationship?	Independent reactions to a fact	Collaborators following a rule or sequence
Example	Several dashboard panels react to a reading	Reserve capacity, then authorize, then confirm
Main ownership question	Who subscribes and unsubscribes?	Who decides the next step and recovery action?
Common mistake	Hiding required ordering in subscriber registration	Putting every business rule into one oversized coordinator

These are decision cues, not mutually exclusive technologies. A mediator centralizes how collaborators interact; it need not implement a multi-step workflow. A coordinator can also publish a fact that observers consume. In this note, “independent” describes the business responsibilities, not a promise of asynchronous execution or failure isolation.

Three assumptions to say aloud

Delivery: Is this a synchronous call, a queued message or a durable event? The pattern name does not guarantee delivery.

Failure: What does a failed handler or ambiguous timeout mean to the caller? Record enough state to recover without repeating a completed effect.

Lifetime: Who owns subscriptions and cleanup? A short-lived screen should not remain attached merely because the provider is long-lived.

A bounded analogy

A notice service lets independent displays subscribe to updates; a booking desk decides which specialist acts next. The first illustrates subscription ownership, the second interaction ownership. Neither analogy promises background execution, durable delivery or automatic recovery.

Worked interview question

A chart and audit panel independently consume temperature readings. A new billing step requires the reading to be persisted first. Should it be just another unordered subscriber?

No. Keep the independent presentation reactions separate, and make persistence-before-billing a visible workflow dependency. The workflow needs a policy for failed persistence, duplicate requests and failed notification after a successful effect. A direct application-service method may be sufficient; a framework is not mandatory.

Quick self-check

Can you identify one invariant, one ordering requirement, one lifecycle boundary and one duplicate case? If not, clarify the contract before adding interfaces.

A worked self-check

For the temperature scenario, one defensible contract is:

• Invariant: bill only for a reading whose persistence has been confirmed.
• Ordering: persist first, then request billing; do not encode this dependency by hoping the persistence subscriber runs first.
• Lifecycle: attach the chart's subscription when the screen becomes active and remove it when that screen is finished.
• Duplicate case: the same reading is submitted again after an uncertain billing result. Give the logical billing operation a stable identity. Reconcile the uncertain result or use a billing API that deduplicates that identity; a local pre-check alone does not protect simultaneous retries. A new random identity for each retry does not identify the duplicate.

If persistence fails, billing is not called. If billing succeeds but a chart update fails, the presentation retry must not bill again. Those policies belong to the workflow and delivery implementation; choosing either pattern does not provide them automatically.

Study the two worked lessons, download the original workbook, or attempt the 8-question Observer, Mediator, Chain of Responsibility and Visitor lesson practice (Full Access).

Sources

• Microsoft: Observer design pattern, for provider/observer roles and subscription ownership.
• Microsoft: keeping controllers under control, for mediator-based separation of communicating components.

Video companions

Dev Leader (Nick Cosentino) demonstrates Observer with System.Reactive and a C# chat mediator. The 2023 examples illustrate mechanics; this note and the worked lessons supply lifetime, failure and recovery boundaries. Neither video is a production booking implementation or a current package-version guide.