Batch pipelines reason in completed files and tables; real-time analytics must also reason about events that arrive late, duplicate messages, stateful windows and streams that never really end. DP-700 includes streaming engine selection, Eventstream processing, Kusto Query Language (KQL) transformations and windowing. The correct answer begins by deciding whether the business needs event-time investigation, near-real-time alerts or periodic aggregation into curated tables.
Trace the event path before opening the designer
Consider a delivery network sending device events containing device_id, event_time, temperature, shipment_id and a unique event_id. The service needs an alert if a container remains above its allowed temperature for ten minutes. A sensible design identifies the producer, ingestion connection, transformation, destination and alert consumer. In Fabric, an Eventstream can route and transform events toward an Eventhouse, other destinations or processing steps depending on supported configuration.
Ask how quickly the alert must arrive and how much out-of-order data must be tolerated. A daily notebook may be acceptable for a trend report but too late for an operational alert. Conversely, keeping an always-on stream merely to recompute yesterday’s totals may be unnecessary expense.
Eventhouse and KQL are a natural fit for time-first questions
An Eventhouse contains KQL databases and tables and is designed for high-volume, time-oriented event analytics. A KQL query can filter a recent window, group by attributes and compute counts or rates without forcing the events into a classic relational dimension/fact structure first. For example:
DeviceEvents
| where event_time >= ago(30m)
| where temperature > 8.0
| summarize hot_readings = count() by device_id, bin(event_time, 5m)
| order by event_time desc
This is an illustrative detection aggregate, not proof that a specific container was above the threshold continuously. A durable alert would also define missing readings, device heartbeat, duplicate event IDs and required consecutive-window logic. A 5-minute bin groups timestamps; it does not automatically handle deduplication or clock drift.
Event time and ingestion time answer different questions
An offline device might upload fifteen minutes of readings after reconnecting. If an alert groups by ingestion time, those readings appear as a burst at reconnection. If it groups by source event time, they belong to earlier windows. The latter can tell a more faithful historical story but requires late-arrival policy and source clock quality. A reliable pipeline records both event_time and ingestion timestamp to distinguish a late event from a temporarily stalled processor.
For a commerce stream, consider a refund event arriving before the associated purchase event. A simple arrival-order state machine might reject it or produce the wrong balance. Decide whether to buffer, reconcile, quarantine or recompute state. Windowing and watermarks express how long the system waits for late records before a result is considered sufficiently complete.
Build transformations around idempotency
Event delivery can be retried. If the same event ID appears twice, counting rows is not equivalent to counting unique business events. Deduplicate by a stable event ID where practical and make downstream updates repeat-safe. If a producer lacks stable identifiers, explain how the resulting uncertainty affects aggregates rather than presenting “exactly once” as a platform-wide guarantee.
For Eventstream operations, test malformed payloads and schema drift. An incoming field might switch from integer to string; a pipeline that drops every such record silently may make operations look healthy while data quality collapses. Preserve a diagnostic route for invalid records and report accepted/rejected volumes.
Understand query acceleration for OneLake shortcuts
The October 2026 study guide distinguishes native Real-Time Intelligence tables, standard OneLake shortcuts and query acceleration for shortcuts. These aren’t the same storage or execution contract. A shortcut can expose data stored in OneLake without copying it into Eventhouse in the traditional ingestion sense; query acceleration is a separate consideration for performance and access patterns. Check connector, data format and current feature support before prescribing an acceleration path.
When deciding whether to use a shortcut or ingest into native Eventhouse tables, compare how frequently the data changes, query concurrency, latency target, storage maintenance and source credentials. Query acceleration can improve access for appropriate workloads, but cannot repair invalid timestamps, missing source records or bad joins. The OneLake reference-vs-copy article explains the ownership trade-off.
Troubleshoot in the order data travels
When an Eventhouse chart stops updating, first identify whether the producer is emitting events. Then inspect the Eventstream’s ingestion status and transformations, check destination mapping and table schema, and only then investigate the KQL query. A query filtering ago(5m) may look empty because source devices report stale timestamps, not because ingestion failed. Comparing event time, ingestion time and last received event ID isolates this quickly.
Measure input rate, rejected records, end-to-end latency and output table row growth. If the ingestion path is healthy but a query is slow, inspect the range scanned and the shape of its aggregation. Use sufficiently selective time predicates and avoid expensive broad joins without a measured requirement. Slow dashboards and missing events require different fixes.
One small operational lab
Generate synthetic delivery events for three devices. Send a normal stream, then intentionally duplicate one event, delay several events by twelve minutes and inject one malformed record. Create a query for five-minute heat counts and a separate freshness check comparing now() to the latest ingestion timestamp. Evaluate whether the detected count changes when late events arrive and document the accepted lateness window.
Finally compare this design with Spark Structured Streaming. The Spark option may fit code-intensive transformations with Delta writes and durable checkpoints, whereas Eventstream and Eventhouse can better match low-code routing and interactive KQL investigations. DP-700 asks you to make that workload-dependent choice and explain the failure path, not to assume a single streaming technology for every event.