Conservation sensors in a museum's rare-manuscripts vault emit humidity, light, and vibration readings continuously, and curators want alerts within seconds of an out-of-range reading. Which loading pattern fits this requirement?
Select an answer to reveal the explanation.
Short Explanation
When curators need to know within seconds, waiting for the next scheduled run defeats the purpose. A streaming loading pattern processes each reading the moment it lands, instead of collecting a batch and hoping the batch window is short enough.
Full Explanation
A streaming loading pattern ingests each event as it arrives and pushes it through processing continuously, which is what a seconds-level alerting requirement demands: any batching interval, however short, adds latency the scenario cannot tolerate. This typically means an Eventstream capturing the sensor feed and routing it toward a destination like an Eventhouse or a Lakehouse table, with logic evaluating thresholds as events flow rather than after the fact. A nightly batch load fails outright, since a full day could pass between an unsafe humidity spike and the alert reaching a curator, and conservation limits rarely changing is irrelevant to how fast an anomaly needs to surface. A one-time full historical load addresses backfilling past readings, not the ongoing need to react to new ones, and it never repeats. A scheduled pipeline copy activity running every few hours is still a batch pattern under the hood; shortening the interval does not make it streaming, and hours-long gaps are exactly what the seconds-level requirement rules out. When validating a streaming design, check the actual end-to-end lag from sensor to alert under real load, not just the theoretical latency of the ingestion component, since downstream processing or windowing choices can quietly reintroduce delay.