A real-time case study

At half past three today, Friday, November 13, Ines presented the freezer pilot design to Elena Brandt, with Nikolai, the facilities lead Dana Whitehorse and Walt Hadley in the room. The trial capacity would expire on December 18, and the pilot would start on the F16 on January 4, 2027, so this was the last chance to change the design cheaply. Elena's instruction had been to present it as a case study: the problem, the design, the evidence, the costs, the risks and the plan, and to say plainly what was still unknown.

The problem and the requirements

The problem was the one from lesson 1. On October 17, freezer F-06 at Brandon failed overnight and was found at 7:40 a.m., and about 3,900 dollars of stock was discarded. Ines restated the requirements as numbers, because a design review argues best about numbers.

The design

The design used each part of Real-Time Intelligence for the job it does best, as the earlier sessions had established. Sensors send readings every ten seconds to the IoT Hub, which also keeps routing raw messages to the archive container as a safety net. The eventstream ingests from the IoT Hub, renames and converts fields, filters impossible values and publishes a derived stream. From there, readings go to the eh_sensors eventhouse for second-level queries; hourly summaries go to the lakehouse; Activator watches the derived stream for warm units, silent sensors and low batteries. In the eventhouse, an update policy fills readings_clean, a materialized view keeps each unit's latest reading, and OneLake availability shares readings_clean with Spark and Power BI. The Freezer watch dashboard reads the view and the clean table. A scheduled structured streaming job with an available-now trigger writes ten-minute statistics every 15 minutes.

The evidence

Ines presented what the trial had shown, separating measurements from assumptions. The October archive, loaded into the eventhouse, showed F-06's ten-minute average first exceeding minus 12 in the window starting 3:40 a.m. The two-window rule would have alerted at 4:00 a.m. and put a technician in the store at about 4:50, 2 hours 50 minutes before the shift found it. Previewing the rule against the live data from November 10 to 13 found no defrost false alarms, though two weeks of live data, the requirement, would not exist until November 24. The end-to-end test with cooler C-05's probe in water delivered the alert 20 minutes after the probe went in, two windows, as designed. The live stream's ingestion delay averaged about four seconds.

The cost

Elena's main question was whether the freezer pilot would crowd the F16, which also had to run the nightly loads and serve 140 report readers. Ines brought an estimate in CU-seconds per day, using the trial's capacity metrics where she had them and marked assumptions where she did not.

# Will the pilot fit on an F16? CU-seconds per day (trial measurements and estimates)
f16_per_day = 16 * 86400
always_on = {"eventstream": 0.9, "eventhouse": 1.4, "activator": 0.2, "workspace monitoring": 0.3}   # average CU
daily = {name: cu * 86400 for name, cu in always_on.items()}
daily["ten-minute stats job"] = 96 * 90 * 4              # 96 runs of 90 s at 4 CU
daily["dashboard queries"] = 23_040 * 2                 # 23,040 queries at about 2 CU-seconds each
daily["nightly loads and model refresh"] = 310_000       # measured on the trial
daily["store manager reports"] = 260_000                 # estimated from trial reports

total = sum(daily.values())
for name, v in sorted(daily.items(), key=lambda kv: -kv[1]):
    print(f"{name:32s} {v:>9,.0f} CU-s  {v / f16_per_day * 100:5.1f} in 100")
print(f"{'total':32s} {total:>9,.0f} CU-s  {total / f16_per_day * 100:5.1f} in 100 of an F16 day")
freezer = sum(daily[k] for k in ("eventstream", "eventhouse", "activator", "ten-minute stats job", "dashboard queries"))
print(f"freezer pilot alone: {freezer / f16_per_day * 100:.1f} in 100")

nightly loads and model refresh    310,000 CU-s   22.4 in 100
store manager reports              260,000 CU-s   18.8 in 100
eventhouse                         120,960 CU-s    8.8 in 100
eventstream                         77,760 CU-s    5.6 in 100
dashboard queries                   46,080 CU-s    3.3 in 100
ten-minute stats job                34,560 CU-s    2.5 in 100
workspace monitoring                25,920 CU-s    1.9 in 100
activator                           17,280 CU-s    1.2 in 100
total                              892,560 CU-s   64.6 in 100 of an F16 day
freezer pilot alone: 21.5 in 100

The total came to about 65 in 100 of the F16's daily capacity, with the freezer pilot itself about 22 in 100. Two cautions went with it. An average day hides peaks: the morning reports and the overnight loads concentrate use, which is what smoothing absorbs and what throttling punishes, so the peak smoothed use would need watching every Monday, as lesson 8 recommended. And the always-on figures were averages over three days of live data, too few to trust fully. Elena accepted the budget on condition that the team set a review threshold: if peak smoothed use passed 80 in 100 in any week, the team would either move the dashboard queries to longer intervals, schedule the statistics job hourly, or bring forward the decision on an F32.

Questions from the room

Walt asked why the eventhouse and the lakehouse both held freezer data. Ines answered with the readers: facilities technicians investigating an incident needed every reading, queried in seconds, which is what the eventhouse is for; the finance team's insurance records and the monthly Power BI report needed hourly figures for years, which a Delta table holds cheaply and which every Fabric engine can read. OneLake availability meant the detailed readings were also reachable from Spark when someone needed them, without a second copy to maintain. Dana asked what would happen to the alerts if the capacity were throttled. Nikolai explained that Activator respects the capacity's state, so a severely throttled capacity could delay alerts, which was one more reason for the 80 in 100 review threshold and for keeping heavy one-off jobs away from the pilot's capacity. Elena asked the last question, the one she always asked: what would make them stop the pilot? Ines's answer was two false alarms in a week that facilities judged avoidable, or a missed real failure, either of which would send the design back for review.

Operating the pilot

A design is only as good as how it is run, so Ines's next slides covered operations. Facilities owned the response to temperature alerts and had a runbook from lesson 5. The data team owned the pipeline itself: the heartbeat rule, the stream health tile, the row-count comparison between readings and readings_clean from lesson 11 and the workspace monitoring eventhouse. Changes would go through Git and the FDH Stores deployment pipeline, Dev to Test to Prod, with the Activator rules deployed stopped and started deliberately after each release, and with the rule from lesson 11 that no eventhouse column is renamed without checking what refers to it.

Risks and unknowns

Elena asked for the risks in plain words, and Ines gave five. The defrost rule had only four days of live evidence; two weeks were required, and the start of the pilot would be delayed if a false alarm appeared before November 24. Wireless outages longer than fifteen minutes would delay the ten-minute statistics beyond the watermark and drop some readings from that table, though not from the eventhouse. The IoT Hub was a single route in; if it failed, every unit would go silent at once, which the heartbeat rule would report but could not fix. The capacity estimate rested on three days of live data. And the gateway that fed the nightly loads still had a single member until January, which did not affect the freezers but did affect the capacity budget if failed loads had to be rerun during the day.

Dana added a risk from her side: the on-call technician's phone needed the Teams app with notifications allowed out of hours, which facilities would check for each person on the rota. Elena noted that this was exactly the kind of risk that no amount of engineering inside Fabric could remove.

The decision and the plan

Elena approved the pilot with three conditions: two weeks of clean defrost evidence by November 24, the 80 in 100 capacity review threshold, and a written check of every on-call phone. The plan that went into the hub's design table had five dates, all of them future: November 24, the defrost evidence review; December 1, deployment to FDH Stores [Test]; December 14, a full rehearsal with facilities, including a simulated failure out of hours; January 4, 2027, go-live on the F16 at Brandon; and February 1, a review to decide whether to add sensors at two more stores.

Looking back over the course

Ines's last slide mapped the pilot to the DP-700 skills these sessions had covered, which Nikolai suggested she keep for her own exam revision in May. Streaming ingestion and processing: the eventstream, KQL update policies, Spark structured streaming and windowing with a watermark. Monitoring: the Monitor hub, run histories, notebook snapshots, workspace monitoring, semantic model refresh history, the capacity metrics app and Activator alerts on job events. Errors: six incidents across pipelines, dataflows, notebooks, the warehouse, the eventstream and the eventhouse. Optimization: lakehouse table maintenance, Spark settings, warehouse predicates and gold tables, pipeline shape, and eventstream and eventhouse choices such as materialized views and caching. Nikolai's habit question had run through all of it: who reads this data, and how fast do they need it?