The Observer Pattern in .NET — Events, Streams, and Awareness

Change Is Easy. Notifying the Right Things Is Hard.

In software systems, state changes constantly—but the real challenge lies in propagating those changes to the right parts of the system without creating tight coupling.

The Observer Pattern addresses this directly. It defines a one-to-many relationship where a subject notifies its observers when its state changes, without knowing who those observers are or what they do.

This is not just about decoupling—it is about controlled awareness. The subject emits signals; observers decide how to react.

The Core Mechanics: Subject and Observers

At a mechanical level, the pattern has three moving parts: a subject that maintains state and emits notifications, one or more observers that subscribe to those notifications, and a subscription mechanism that connects them.

In .NET, this is most commonly implemented using events:

public class OrderService
{
    public event EventHandler<
    OrderPlacedEventArgs> OrderPlaced;

    public void PlaceOrder(Order order)
    {
        Save(order);
        OrderPlaced?.Invoke(this, 
        new OrderPlacedEventArgs(order));
    }
}

Observers attach themselves independently:

orderService.OrderPlaced += 
EmailNotifier.Handle;
orderService.OrderPlaced += 
InventoryUpdater.Handle;

This model keeps the subject unaware of its observers, allowing new behaviors to be added without modifying existing code. However, standard events are intentionally lightweight. They do not model completion, they do not provide structured error propagation, and they offer limited control over subscription lifecycles.

Beyond Events: IObservable<T> and IObserver<T>

The .NET ecosystem extends the Observer Pattern through IObservable<T> and IObserver<T>, where notifications are treated as a stream rather than isolated signals.

public class NumberObserver : 
IObserver<int>
{
    public void OnNext(int value)
    {
        Console.WriteLine
        ($"Received: {value}");
    }

    public void OnError(Exception error)
    {
        Console.WriteLine
        ($"Error: {error.Message}");
    }

    public void OnCompleted()
    {
        Console.WriteLine
        ("Stream completed");
    }
}

Subscribing becomes explicit and controllable:

IObservable<int> stream = 
GetNumberStream();
IDisposable subscription = 
stream.Subscribe(new NumberObserver());

This model introduces important capabilities absent in events. Observers are informed when a sequence completes, errors are part of the contract rather than side effects, and subscriptions can be explicitly disposed to avoid leaks.

This is the foundation of reactive programming in .NET. Instead of reacting to isolated triggers, systems can describe and compose flows of data over time.

When to Use Events vs. Observables

The choice between events and observables depends on the nature of the problem.

Events are appropriate when notifications are simple, instantaneous, and do not represent an ongoing sequence. They are easy to implement and sufficient for many domain-level signals.

IObservable<T> becomes valuable when dealing with streams, asynchronous flows, or scenarios where completion and error handling are first-class concerns. It allows richer composition and more predictable lifecycle management.

In essence, events notify; observables describe evolving processes.

Observer Pattern in ASP.NET: Where It Fits—and Where It Doesn’t

While it might be tempting to relate the Observer Pattern to middleware, they serve fundamentally different purposes.

In ASP.NET, the Observer Pattern is best understood through in-process domain and application events, not through middleware.

Middleware in ASP.NET Core follows a pipeline (chain-of-responsibility) model. Each component decides whether to pass control forward, which is fundamentally about request flow rather than observation. Treating middleware as an observer system can lead to confusion, especially for those trying to understand the pattern for the first time.

A more accurate and practical application appears in domain event handling. Using libraries like MediatR, the Observer Pattern becomes explicit and structured.

A notification represents the event:

public class OrderPlacedNotification : 
INotification
{
    public Order Order { get; set; }
}

Observers subscribe through handlers:

public class EmailHandler : 
INotificationHandler<OrderPlacedNotification>
{
    public Task Handle
    (OrderPlacedNotification notification, 
    CancellationToken token)
    {
        // Send email
        return Task.CompletedTask;
    }
}

The publishing side completes the picture and typically resides in an application service:

public class OrderService
{
    private readonly IMediator _mediator;

    public OrderService(IMediator mediator)
    {
        _mediator = mediator;
    }

    public async Task PlaceOrder(Order order)
    {
        Save(order);

        await _mediator.Publish
        (new OrderPlacedNotification
        {
            Order = order
        });
    }
}

Here, OrderService emits a notification without knowing which handlers will respond. This preserves the essence of the Observer Pattern—decoupling the source of change from its consequences—while fitting naturally into modern ASP.NET Core architecture.

From In-Process Observers to Distributed Pub/Sub

So far, the examples operate within a single process. In real-world systems, this idea often extends across service boundaries.

Instead of notifying in-memory observers, an application may publish an event to a message broker. Other services—email, billing, analytics—subscribe independently and react in their own contexts.

This is the Publish/Subscribe (Pub/Sub) pattern, which can be understood as a distributed evolution of the Observer Pattern. The core idea remains unchanged: a publisher emits events without knowledge of its consumers, and subscribers react independently.

The difference lies in infrastructure and scale. What begins as an in-process observer relationship can grow into a fully event-driven architecture spanning multiple services.

Managing Complexity: The Hidden Trade-Off

While the Observer Pattern reduces direct coupling, it introduces indirect complexity. A single action can trigger multiple observers, and the overall flow of execution becomes less explicit.

This can make systems harder to reason about if not managed carefully. Side effects may accumulate, execution order may become unclear, and debugging may require tracing across multiple observers.

Maintaining clarity requires discipline. Observers should remain focused, side effects should be intentional, and tracing mechanisms such as logging should be in place to make the system’s behavior visible.

Awareness as a Design Choice

The Observer Pattern ultimately raises a deeper design question: what should be observable?

Not every change deserves to be broadcast. Not every component needs to listen. Overuse can lead to noisy systems where signals lose meaning.

Effective design comes from selectivity. Emit events that represent meaningful domain changes, attach observers where there is clear responsibility, and avoid unnecessary propagation of state.

This restraint is what keeps the system understandable as it grows.

A Parallel Beyond Code

There is a subtle parallel between the Observer Pattern and human cognition.

At any given moment, countless signals exist within and around us, yet only a few reach conscious awareness. This selectivity is not a limitation—it is what allows clarity to emerge.

If every stimulus demanded equal attention, perception would collapse into noise.

Software systems face a similar challenge. The Observer Pattern provides a way to distribute awareness—but it is the designer’s responsibility to ensure that what is observed remains meaningful.

Closing Thoughts

In .NET and ASP.NET development, the Observer Pattern provides a foundation for building flexible and extensible systems.

From simple C# events to IObservable<T> streams, and further into distributed Pub/Sub architectures, the same principle persists: changes occur, and interested parties respond—without tight coupling between them.

Understanding the mechanics is important. Applying them with intention is what makes the pattern truly effective.

That’s all for now. May your intention be clear and your mind be still. With this quiet wish, I rest my pen and return to the silence.