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 |
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.
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.
Study the two worked lessons, download the original workbook, or attempt the six-question practice test.