Build event-driven architectures in Fabric with Real-Time Hub

Microsoft Employee

2 months ago

Welcome to the first post in our Business Events, Fabric Events, and Azure Events series for Microsoft Fabric. Whether you're new to event-driven architectures or looking to build enterprise-grade event-driven solutions, this series will take you from foundational concepts to real-world implementation patterns. We'll start with the basics and progressively explore event design, event publishing, event consumption, automation, and production-ready architectures across Microsoft Fabric.

In this blog post, you’ll learn why event-driven architecture matters in Microsoft Fabric, how it changes the way Fabric workloads communicate, and where Real-Time Hub fits in the model. Data engineers, data analysts, and developers will gain a practical mental model for building Fabric workloads that react when something happens.

Why this matters

A store's point-of-sale integration stops sending transactions at 9:15 AM. The dashboard doesn’t show an obvious problem until someone opens it at 11:00 AM and sees the flat line. By then, the issue is no longer just operational. The team now has to reconstruct what happened, when it started, who noticed, and which downstream workloads consumed incomplete data.

Microsoft Fabric’s event-driven architecture helps close this kind of gap.

Many data workloads still run on a schedule. A job starts every few minutes or every hour, checks if anything has changed, and then decides if there’s work to do. That approach is familiar and useful, but it also creates latency when something important happens right after the last run. It can also spend compute checking for work when nothing has changed.

Event-driven thinking starts with a different question: what meaningful thing happened, and who needs to know right now?

Figure: Scheduled polling checks for changes on a clock, while event-driven workloads react when a meaningful signal is published.

The Fabric mental model

In Fabric, events flow through Real-Time Hub. A publisher emits a signal. Real-Time Hub receives it. One or more consumers react.

The publisher doesn’t need to know who’s listening and the consumer doesn’t need to know how the event was detected. This separation makes the pattern powerful for teams that are growing, sharing ownership, or adding new reactions over time.

That separation also changes how teams collaborate. In a scheduled model, the upstream workload often has to know what should happen next. In an event-driven model, the upstream workload only publishes a clear signal. Teams that care about that signal can subscribe, define their own reaction, and evolve independently.

This matters because Fabric brings different personas into the same data estate. A data engineer may own the Notebook that detects the condition. A data analyst may own the Eventhouse query or dashboard that explains the pattern over time. A developer may own the User Data Function that normalizes an external payload. Event-driven architecture gives each persona a clean boundary.

How Fabric supports this pattern

Fabric supports this pattern through three event pillars based on where the signal originates:

Business Events: signals your Fabric workloads publish when something meaningful happens in your business domain.
Fabric Events: signals emitted by the Fabric platform.
Azure Events: signals from Azure Storage Accounts that Fabric can consume and react to.

For Business Events, the publishers are workloads that generate business signals, such as Activator, Spark Notebooks, and User Data Functions. Once published, these events become available through Real-Time hub, where they can be consumed by experiences including Activator, Eventhouse, User Data Functions, Notebooks, Spark Jobs, Dataflows Gen2, Power Automate, and Real-Time Dashboards.

For Fabric Events, the publisher is Fabric itself. Consumers are Activator and Eventstream.

For Azure Events, the publisher is Azure Storage Accounts. Consumers are Activator and Eventstream.

What this means for your role

For data engineers, event-driven patterns reduce fragile handoffs. A Notebook can publish a sales volume alert without directly calling every downstream workload. If a new consumer is added later, the Notebook does not change.

For data analysts, events can land in Eventhouse as queryable records. That means KQL queries, Real-Time Dashboards, and operational views can reflect what happened seconds ago instead of waiting for the next scheduled refresh.

For developers, Business Events provide a schema-defined contract. You define the event shape before publishing, send a versioned payload, and let consumers subscribe independently.

A practical first step

The best first event isn’t the most complex one. Pick a signal that is easy to explain and painful to miss.

Take a retail team that monitors store transaction volume. Here is what a first Business Event looks like for that scenario.

Event: Retail.Sales.VolumeAlert

The event carries the fields that matter to the business: store_id, expected_transactions, actual_transactions, deviation_pct, and severity. Those fields are the contract between the publisher and every consumer. Both sides agree on what the event means before any code runs.

Publisher: Fabric Notebook

The Notebook runs the calculation: it compares expected and actual volume per store. In this example, when a store drops more than 30% below baseline, the Notebook publishes the event to Real-Time Hub. It does not call any downstream system directly. It declares that something meaningful happened and moves on.

Consumer: Activator

Activator subscribes to that event, evaluates the severity field, and sends a Teams message to the operations team with the store ID and the numbers. If a second team later wants a historical record, they can subscribe to the same event through Eventhouse — without asking the Notebook or Activator to change.

That is the shape of a good first event: a clear name, a few meaningful fields, one publisher that owns the detection, and one consumer that owns the reaction.

If you need to spend ten minutes explaining why the event matters, it is probably not the first one to build. Start where the value is immediate: someone should be notified, a dashboard should show it, or a team should be able to query it later.

For more end-to-end patterns, refer to the Fabric Events scenarios guide.

Conclusion and where to go next

Event-driven architecture in Fabric is about making workloads react to meaningful events instead of waiting for the next scheduled check. Real-Time Hub provides the common entry point, and the event pillar you choose depends on who publishes the signal.

To continue, explore the community guide and the official Business Events documentation.

Business events in Fabric series

This article is the first installment in an eight-part series exploring Business Events and event-driven architecture in Microsoft Fabric. Throughout the series, we'll cover the concepts, patterns, and implementation guidance needed to design, publish, process, and scale business events across Fabric workloads.

In the next article, we'll explore the three Fabric event pillars and explain when to use Business Events, Fabric Events, and Azure Events.

Article links