Ask ten stakeholders why they want "real-time" data and most of them mean something closer to "faster than the overnight batch job we have now." Fabric Real-Time Intelligence - the workload built around Eventstreams, Eventhouse, and Data Activator - solves a genuinely different problem: data that needs to be ingested, analysed, and acted on within seconds of an event happening, not data that's merely inconvenient to wait a few hours for. Confusing the two is the single most common reason Real-Time Intelligence projects either get built when a scheduled refresh would have done the job just as well, or get dismissed as unnecessary complexity when it was actually exactly the right tool.

This guide covers what Real-Time Intelligence actually is architecturally, the specific signals that tell you whether you have a genuine sub-minute latency requirement or a refresh-frequency preference, what the workload replaces when you do need it, and where its current limits mean a different tool is still the better choice.

What "Real-Time" Actually Means in Fabric

Real-Time Intelligence is a single Fabric workload built from four components working together on one governed capacity. Eventstream is the ingestion layer - a declarative, largely no-code pipeline connecting to more than two dozen source types, including Azure Event Hubs, IoT Hub, Kafka and Confluent Cloud, Amazon Kinesis and MSK, Google Pub/Sub, MQTT brokers, and database change data capture from sources like Azure SQL, PostgreSQL, and Cosmos DB. Eventhouse is the storage engine underneath it - a KQL-backed, columnar store evolved from Azure Data Explorer, purpose-built for time-series and high-cardinality event data rather than the relational structure a warehouse or lakehouse assumes. A KQL Database inside that Eventhouse exposes the data for querying, in Kusto Query Language natively or T-SQL through the KQL queryset. And Data Activator sits on top of all of it as a no-code condition-and-action engine - define a threshold, an anomaly pattern, or a rule, and it fires an alert, a Teams message, a Power Automate flow, or an API call the moment the condition is met, continuously, without anyone watching a dashboard.

The Real Question: Do You Have a Latency Problem?

Before evaluating Eventstreams at all, it's worth being honest about which problem is actually being solved. A dashboard that refreshes every few hours and frustrates a stakeholder who wants same-day numbers is a refresh-frequency problem, and it's solved by tightening a scheduled Power BI refresh or moving to Direct Lake mode - neither of which requires standing up a streaming pipeline. A genuine latency problem is different in kind, not just degree: it's a scenario where the value of the data measurably decays within minutes or seconds, and where someone or something needs to act before that decay happens, not just be informed after the fact at the next convenient interval.

Five Signals You Genuinely Need Eventstreams

What Eventstreams Actually Replace

For organisations that do have a genuine streaming requirement, the value proposition is consolidation as much as capability. The traditional real-time stack most enterprises assemble independently - Kafka for ingestion, a dedicated time-series database like ClickHouse for storage, and Grafana for visualisation, or the Azure-native equivalent of Event Hubs feeding a custom Stream Analytics job into a separate database - means every piece has its own billing model, its own security boundary, and its own failure mode. When something breaks at 2am, several different teams get paged for what is, conceptually, one pipeline. Real-Time Intelligence replaces that fragmented assembly with Eventstream, Eventhouse, and Activator running on the same governed Fabric capacity as the rest of the platform, under one security model and one bill.

A Worked Example: Order Cancellation Alerting

A concrete pattern illustrates how the pieces fit together in practice. An e-commerce company mirrors its operational order database into Fabric via change data capture, with those change events flowing into an Eventstream in near real time. Inside the Eventstream, the team applies a filter to isolate only high-value order cancellations, and enriches each event with the customer's tier from a reference dataset. The processed stream routes to two destinations simultaneously: Eventhouse, feeding a live revenue-impact dashboard that updates as cancellations happen, and Data Activator, configured to post an alert directly to the customer-success team's Teams channel whenever a premium-tier customer cancels an order above a defined value threshold. The entire pipeline - filter, enrich, store, alert - runs without a scheduled job anywhere in it, and the customer-success team is notified within seconds of the cancellation happening, not the next morning when someone happens to check a report.

The Latency Tradeoffs You're Actually Choosing Between

Even within Real-Time Intelligence, "real-time" isn't a single latency number - it's a set of architectural choices with real tradeoffs.

Choosing between these isn't a technical afterthought - it should be driven by the actual SLA a specific use case needs. Reaching for the lowest-latency option by default when a 30–90 second lag was genuinely acceptable adds architectural complexity without adding real business value.

Where Eventstreams Are Overkill - or Not Yet Ready

Decision Framework

A simple gut-check: if the answer to "what happens if this data is three hours old instead of three seconds old" is "nothing meaningfully changes," you almost certainly don't need Eventstreams yet - and building them anyway adds ongoing operational complexity for a latency requirement nobody actually has. If the answer involves a missed fraud window, a safety threshold, an SLA breach, or a customer experience that degrades measurably with delay, that's the genuine signal to invest in the architecture this guide describes.

Numlytics scopes Microsoft Fabric implementations against the workload your data actually requires - Real-Time Intelligence where a genuine latency requirement exists, and a simpler, lower-cost architecture where it doesn't. Explore our Microsoft Fabric migration practice or speak with a certified consultant about whether your use case genuinely needs Eventstreams.