Observer Pattern

Observer means the thing that changed announces what happened, and whoever cares reacts. The announcement does not name its audience, so a new reaction is a new class rather than an edit to the code that raised it.

The pain it answers is a method that keeps growing. Approving an invoice started as a status change. Then it emailed the customer. Then it updated a finance dashboard, wrote an audit row, and nudged a reporting table. Five reasons to change in one method, and the fifth was added by someone who had to understand the other four first.

// The fact, in the past tense, carrying what a reactor needs
public sealed record InvoiceApproved(
    int InvoiceId,
    string Number,
    decimal Total,
    DateTime ApprovedUtc);

public interface IHandle<in TNotification>
{
    Task HandleAsync(TNotification notification, CancellationToken token);
}

internal sealed class EmailCustomerOnApproval(ICustomerNotifier notifier)
    : IHandle<InvoiceApproved>
{
    public Task HandleAsync(InvoiceApproved approved, CancellationToken token) =>
        notifier.InvoiceApprovedAsync(approved.Number, approved.Total, token);
}

public sealed class InProcessPublisher(
    IServiceProvider services,
    ILogger<InProcessPublisher> log) : IPublisher
{
    public async Task PublishAsync<TNotification>(
        TNotification notification, CancellationToken token)
    {
        foreach (IHandle<TNotification> handler in services.GetServices<IHandle<TNotification>>())
        {
            log.LogInformation("Handling {Notification} with {Handler}.",
                typeof(TNotification).Name, handler.GetType().Name);

            await handler.HandleAsync(notification, token);
        }
    }
}

• The notification is a record in the past tense. That naming is a design constraint, not a style rule: a fact cannot be refused, so a handler that fails does not undo it. Name it SendApprovalEmail and you have written an instruction, which belongs in a direct call.
• The in on the type parameter makes the interface contravariant, so a handler written against a base notification type can receive a derived one. Useful for a single audit handler covering a family of events.
• The publisher resolves handlers from the container and knows none of them by name. Adding a finance dashboard update is one class and one registration, with no change to the approval code.
• The log line inside the loop is the most important line in this example. Without it, nobody reading production logs can tell which reactions ran, and that is the cost this pattern imposes.
• Two behaviours here need a deliberate decision. The loop is sequential in registration order, so a slow handler delays the response and an accidental dependency on ordering will appear to work. And an exception in the second handler abandons the third, leaving the work half done with the fact already true.

public sealed class InvoiceFeed
{
    // Long-lived: registered as a singleton.
    public event EventHandler<InvoiceApprovedArgs>? Approved;

    public void Announce(InvoiceApprovedArgs args) => Approved?.Invoke(this, args);
}

public sealed class ApprovalAuditWatcher : IDisposable
{
    private readonly InvoiceFeed _feed;

    public ApprovalAuditWatcher(InvoiceFeed feed)
    {
        _feed = feed;
        _feed.Approved += OnApproved;   // subscribe
    }

    private void OnApproved(object? sender, InvoiceApprovedArgs args)
    {
        // write an audit row
    }

    // Remove this method, or fail to dispose the watcher, and the leak is live.
    public void Dispose() => _feed.Approved -= OnApproved;
}

• The += stores a reference to OnApproved, which holds a reference to the watcher instance. The feed is a singleton, so that reference outlives the request the watcher was created for.
• Nothing is ever collected. A watcher created per request means the feed's invocation list grows for the lifetime of the process, and each dead watcher still runs when the event fires.
• The symptoms arrive in this order: memory climbs slowly, then the same audit row appears several times, then dozens of times. By the time anyone notices the duplicates, the memory graph has been odd for a fortnight.
• Two fixes. Match every += with a -= and make sure the subscriber is disposed — which means something has to own its lifetime. Or avoid instance subscriptions entirely and resolve handlers per notification, as the previous example does, so there is no list to grow.
• This catches nearly everyone once. It is the specific reason many teams prefer resolved handlers over .NET events for anything longer-lived than a single object graph.

Everything above happens in one process, inside one transaction boundary if you choose. That keeps two properties you should notice while you have them: a handler either ran or threw, and nothing was delivered twice.

The next module takes the same idea across process boundaries, where neither property holds. Once a fact travels over a network, it can arrive twice, arrive late, or arrive out of order, and every handler has to be written for that. The pattern looks the same; the guarantees do not.