Fabric Real-Time Intelligence connects event ingestion, stream processing, analytical storage, queries and reactions. A typical path uses Eventstreams to receive and route supported events, Eventhouse with KQL databases to store and analyze them, and dashboards or controlled actions to make the result useful. Define the actual source-to-decision latency target rather than treating “real time” as a universal guarantee.

Key takeaways

• Separate event time from ingestion time and define how late data is handled.
• Version the event contract and test schema changes before release.
• Choose retention and caching for different purposes.
• Give alerts an owner and prevent repeated events from causing duplicate actions.

What Eventstreams, Eventhouse and KQL each do

Microsoft’s Real-Time Intelligence overview describes an event-focused analytics path from discovery and ingestion to visualization and actions. These components can be combined according to the workload; every use case does not need every available item.

Eventstreams provides supported event sources, optional transformations and routing to destinations. Source and destination availability varies, and schema-aware experiences can have a different feature status from the established experience. Check the selected configuration rather than assuming all preview capabilities are production requirements.

Eventhouse groups databases for event analytics and management. KQL databases provide tables and query capabilities for time-based and other analytical exploration. Kusto Query Language expresses filters, aggregations and other analytical operations. A streaming route and a query store solve different parts of the problem.

Reference architecture: operational event visibility

Operational event producer
  → authenticated supported ingestion source
  → Eventstream validation / routing
  → Eventhouse and KQL database tables
  → KQL analysis and monitored views
  → dashboard or owned alert
  → reviewed action where required

Across the path: event contract, access control,
latency measurements, failure handling and retention.

Assign one owner to the event contract and another, where appropriate, to the analytical product. The producer must explain what an event means; the consuming team must explain how a metric or alert interprets it. Without that boundary, a source change can silently alter the business meaning of a dashboard.

Keep analytics separate from safety-critical or irreversible control unless the system has the appropriate validated architecture. A dashboard threshold alone should not be treated as authority to execute a consequential action.

Define the event contract before tuning throughput

Document a stable event identifier, event timestamp, source identifier, schema version and relevant measurement units. Decide whether retries reuse the event identifier and how duplicates are recognized. Record which fields can contain sensitive information and avoid collecting unnecessary payload content.

{
  "event_id": "illustrative-event-001",
  "schema_version": "1",
  "event_time_utc": "2026-11-03T08:00:00Z",
  "source_id": "test-device-07",
  "event_type": "status_observation",
  "value": 42.0,
  "unit": "declared_test_unit"
}

This is a fictional event envelope, not a required Fabric schema. A real contract must specify valid ranges, nullable fields and timestamp interpretation. Reject or quarantine invalid records through a supported implementation rather than silently coercing everything into a successful ingestion count.

Event time and ingestion time answer different questions

Event time indicates when the source says the observation occurred. Ingestion time indicates when the analytics platform received it. Clock errors, offline devices and retry backlogs can create a gap. Measure both if your business question requires them.

Define late-arrival behavior explicitly: include late events in a corrected historical view, flag them for review or apply another documented rule. Do not claim a completed five-minute window is final if the system later revises it without notification.

A small KQL aggregation example

The following illustrative query assumes a table named DeviceEvents with the shown timestamp and source columns. It has not been executed against a Fabric tenant. Validate types, access rules and query behavior in your test environment before using it.

DeviceEvents
| where EventTimeUtc >= ago(1h)
| summarize Observations = count()
    by SourceId, bin(EventTimeUtc, 5m)
| order by EventTimeUtc asc

This counts stored rows by source and five-minute event-time bucket. It does not deduplicate events, establish device health or prove ingestion completeness. If the source retries records, decide how a valid unique observation is defined before turning the count into an operational metric.

Test the query with known fixtures: two records in one bucket, a boundary timestamp, a repeated event and an event arriving late. Compare expected counts with actual outputs. A query that returns results is not necessarily answering the intended business question.

Schema changes, retention and caching

Schema changes are a producer-consumer release

Classify changes as additive or potentially breaking. A new optional field differs from a changed unit, renamed identifier or timestamp type. Version the contract and test downstream mappings, queries and alerts before a producer releases the change.

Preserve a controlled route for invalid or unfamiliar events where the chosen ingestion pattern supports it. Monitor rejected and unmapped records. A sudden reduction in event volume can be a parsing failure rather than a quiet business period.

Retention and cache serve different goals

Retention determines how long data is kept under the chosen policy. Caching concerns the performance of access to retained data. Set each from business and operational requirements, then verify the current database and table settings using the supported management interface.

Agree on raw-event and derived-output retention separately. A short raw retention period may prevent later investigations even if an aggregated chart remains. Conversely, retaining every payload forever increases cost and information exposure without a justified purpose.

Where data is made available through other Fabric experiences, verify how retention and schema changes affect those consumers. Do not assume a secondary access path creates an independent archive.

Decision and operational checklist

Measure normal traffic, bursts, source interruptions and catch-up. Record capacity and concurrent workloads. Use the Fabric capacity planning guide rather than sizing from a single low-volume demonstration.

Keep alerts actionable

Specify the owner, severity and expected response for each alert. Add deduplication or suppression appropriate to the workflow so repeated observations do not create repeated tickets or actions. Test missing-data alerts separately from out-of-range-value alerts; absence is a different signal.

Common questions

Build an event path with measurable outcomes

Use the ingestion-pattern comparison to review alternatives. Plan your Microsoft Fabric implementation with a versioned event contract, validated queries and an owned response process.