Hot, Warm, and Cold Data Paths on Azure
Analytics architectures usually split incoming data across several paths, not because the data differs but because the urgency does. The same telemetry might need to raise an alert within seconds, feed a dashboard within minutes, and contribute to a monthly trend report. Trying to serve all three from one pipeline produces something that's either too slow for the alert or too expensive for the report.
The hot, warm, and cold path model is how that gets separated.
The three paths
A hot path processes or displays data in real time, for real-time alerting and streaming operations. It's where latency-sensitive results need to be ready in seconds or less, flowing straight to analytics clients. The refrigerated trailer whose temperature just crossed a threshold belongs here — the value of that information decays to nothing within minutes.
A warm path analyses data as it flows through the system, processed in near real time, saved to warm storage, and pushed to analytics clients. Dashboards and operational views live here: fresh enough to act on, without the cost of true real-time processing.
A cold path handles batch processing over historical data, where latency doesn't matter and completeness does. Monthly reporting, trend analysis, model training. The cold path is allowed to be slow because nothing is waiting on it, which is what lets it be cheap and thorough.
Most real architectures run at least two of these over the same ingested stream, with the hot path branching off early and the full stream landing in a data lake for the cold path to work through later.
Azure Stream Analytics
Consuming data streams, analysing them, and deriving actionable insight is stream processing. Azure Stream Analytics is a fully managed PaaS real-time analytics and complex event-processing engine, running analytics over multiple streams from IoT devices, sensors, clickstreams, and social media feeds.
It's the service that typically implements the hot and warm paths.
Data streams
Data streams are continuous data generated by applications, IoT devices, or sensors, analysed to extract actionable insights. Monitoring industrial and manufacturing equipment, or water pipeline data for a utility provider, are the canonical examples.
The framing worth keeping: streams are what let you understand change over time. A stream isn't just a fast table — the ordering and the timing carry meaning that a snapshot doesn't have.
Event processing
Event processing is the consumption and analysis of a continuous stream to extract insight from the events within it. Events carry temporal information: a car passing through a tollbooth includes a timestamp marking when it happened, and that timestamp is what makes windowed aggregation — counts per minute, averages per hour — possible at all.
Stream Analytics processes events in three formats: CSV, JSON, and Avro.
Where it sits in a pipeline
Stream Analytics rarely stands alone. A typical arrangement:
- Ingestion through IoT Hub or Event Hubs.
- Hot path — Stream Analytics evaluates the stream against rules, raising alerts or feeding a live dashboard (see the Power BI caveat below).
- Warm path — Stream Analytics aggregates over windows and writes results to a store the dashboards query.
- Cold path — the raw stream also lands in Data Lake Storage, where Databricks or Synapse process it in batch later.
Cosmos DB integrates with IoT Hub, Stream Analytics, Notification Hubs, Machine Learning, and Power BI, which is what makes it a common landing place for the warm path's output.
One caveat on dashboards. Stream Analytics' Power BI output depends on real-time streaming in Power BI, which is being retired. From 31 October 2027 you can't create jobs with the Power BI output connector, and existing jobs using it are stopped. Microsoft recommends Real-Time Intelligence in Microsoft Fabric for this. For a design started now, write hot- and warm-path results to a store or service a dashboard queries, rather than building on that connector.
A note on Azure Data Share
Not a path in this model, but adjacent enough to place here: Azure Data Share is built for securely sharing data between organisations, letting one entity share data with partners or customers while keeping control of what's shared. It shares only the specified snapshots, which is what maintains control over information passing between two companies.
It's the answer when the requirement is "give our partner this dataset" rather than "process this dataset" — a governance tool rather than an analytics one, and easy to overlook when the instinct is to grant storage access directly.