46  Edge Stream Window Contracts

analytics-ml
edge
patterns
stream

46.1 Start With the Story

Picture an IoT team using the ideas in Edge Stream Window Contracts during a live operations review. A device has produced messy evidence, an analytic step is about to change an alert or control decision, and someone has to explain why the result should be trusted.

Read this page as that path from sensor evidence to accountable action. Start with what the system observes, keep the model or data treatment visible, and finish with the check that would convince an operator, maintainer, or auditor to act.

46.2 Learning Objectives

After this page, you should be able to:

  • Explain why unbounded IoT streams need explicit window rules before they can produce reliable metrics.
  • Choose tumbling, sliding, or session windows based on the operating question being answered.
  • Estimate how window choice changes edge memory, CPU, and battery load.
  • Specify late-event, timestamp, reboot, and replay metadata so emitted metrics remain auditable.

46.3 Why Windows Follow Edge Patterns

Edge Processing Patterns compares filter, aggregate, infer, and store-forward designs. Those patterns decide where and why work happens. This page narrows in on the stream contract that makes edge outputs interpretable: how a never-ending event flow is carved into finite windows, how much state each window keeps, and what metadata travels with each emitted result.

Use it when a gateway emits local counts, averages, trends, session summaries, exception rates, or model features that downstream systems will compare over time.

46.4 Windowed Stream Computing

Batch analytics runs over a finite dataset that sits still. Edge and streaming analytics face an endless flow of events with no natural “end” at which to compute an average or a count. The answer is the window: you carve the infinite stream into finite chunks and compute over each chunk.

How you carve it determines the meaning of the result. The three fundamental window types – tumbling, sliding, and session – answer different questions, and choosing the wrong one gives numbers that are technically correct but answer a question you did not ask.

Intuition: a window is a stopwatch strategy. Reset it every minute (tumbling), keep a rolling last-five-minutes view (sliding), or start it when activity begins and stop it after a quiet gap (session). Same stream, three very different reports.

Worked example: a cold-chain gateway receives one temperature event every second from each trailer. If operations wants a compliance report, a tumbling one-hour window can produce one non-overlapping min/max/average for each trailer. If dispatch wants early warning that a trailer is warming, a sliding ten-minute window updated every minute gives a fresher trend. If the trailer sleeps between trips, a session window can group each active delivery run and close after a quiet gap. The raw stream is identical in all three cases; the window changes the business question answered by the same events.

This is why the window definition belongs in the data contract. A downstream dashboard that says “average temperature” is ambiguous unless it also says whether the value came from a clock-aligned bucket, a rolling lookback, or one activity session. The wrong window can make alerts late, double-count events, or merge two separate operating periods.

flowchart LR
  A["Unbounded event stream"] --> B{"Choose window rule"}
  B --> C["Tumbling window"]
  B --> D["Sliding window"]
  B --> E["Session window"]
  C --> F["Aggregate and emit result"]
  D --> F
  E --> F

46.4.1 Overview Knowledge Check

46.5 Tumbling, Sliding, Session

Tumbling: fixed size, NON-overlapping, contiguous.
          Every event lands in exactly one window.  e.g. "count per 1 min"
Sliding:  fixed size, OVERLAPPING (slide < size).
          Events fall in several windows.  e.g. "5-min avg, updated every 1 min"
Session:  DYNAMIC length, defined by activity; a window closes after a
          gap (timeout) of inactivity.  e.g. "one user visit"

Worked example: same stream, three answers

Temperature events arriving continuously:

  Tumbling(1 min): one average per clock minute, no overlap
                   -> clean, non-double-counted per-minute stats
  Sliding(5 min, 1 min): a smoothed 5-minute average refreshed
                   each minute -> good for trends/alerts, but each
                   event is counted in up to 5 windows
  Session(gap=30 s): groups bursts of readings from one device
                   wake-cycle; closes 30 s after the last reading
                   -> length varies with the device's activity

Pick by the question: “how many per minute?” is tumbling; “what is the current smoothed rate?” is sliding; “what happened during one burst of activity?” is session. Using a sliding window where you meant tumbling silently double-counts events.

Worked example continuation: suppose the stream has events at 00:05, 00:15, 00:55, 01:05, and 01:40. Tumbling one-minute windows count three events in minute 00 and two in minute 01. A two-minute sliding window updated each minute reports all five events at 02:00 because the lookback overlaps both minutes. A session window with a 30-second gap splits the first three events into one burst and the last two into another. None of those answers is wrong; each reflects a different operating question and a different amount of state held by the gateway.

In a review, write the window rule beside the metric. For example, “door opens per minute” should say tumbling 60 seconds, aligned to the gateway clock, keyed by door id. “Recent vibration trend” should say sliding 5 minutes with a 30-second slide. “Pump run” should say session gap 2 minutes, keyed by pump id. Those labels prevent a maintainer from comparing incompatible numbers.

46.5.1 Practitioner Knowledge Check

46.6 Window State Has Cost

At the edge, where memory is scarce, the practicalities of maintaining windows matter as much as their semantics.

Sliding windows cost more

Because events belong to many overlapping windows, sliding windows keep more in-flight state and recompute more often than tumbling ones. On a constrained gateway, that memory and CPU cost is real.

Incremental aggregation

Sums, counts, and averages can be updated incrementally as events arrive and leave a window, avoiding a full recompute. Percentiles and distinct-counts are harder and often use approximate sketches.

Session gaps need a timeout

A session window cannot close until a gap of inactivity passes, so it holds state until the timeout fires. Choosing the gap is a trade-off between splitting one activity and merging two.

Bounded state or it grows

Every open window is memory. Streaming systems must expire and emit windows promptly; a stuck or ever-growing window is a classic cause of edge memory exhaustion.

So window choice is both a semantic and a resource decision. Tumbling is cheapest and cleanest for periodic aggregates; sliding gives smooth, responsive trends at higher cost; session captures natural bursts of activity but must hold state until a quiet gap. On the edge, the right window is the one that answers the question with the least state held open.

Worked example: a vibration gateway with 128 MB of RAM can keep a one-minute tumbling count as a few counters, but a ten-minute sliding window updated every second may need many overlapping buckets or a ring buffer of recent samples. If the gateway also tracks per-device sessions, each active device keeps its own timeout and partial aggregate. The engineering decision is not just accuracy; it is whether the available memory, CPU, and battery budget can support the state implied by the chosen window.

Make the state budget explicit before implementation. For a 100 Hz vibration stream, a tumbling one-minute average only needs a running sum, a count, and perhaps a min/max pair for the current minute. A sliding ten-minute window with a one-second slide covers 600 seconds of recent data, so a naive design can drift toward 60,000 retained samples per sensor. A practical edge design stores smaller per-second buckets in a ring buffer and subtracts expired buckets as the window advances, but that still multiplies memory by the number of sensors and keyed streams.

The same logic applies to correctness. Late events need a cutoff rule, clock drift needs a timestamp policy, and reboot recovery needs a decision about whether partial windows are replayed, discarded, or emitted with a quality flag. Those operational details are easy to hide in code, but they decide whether edge results are repeatable during outages. A good review therefore checks three items: the window semantics match the question, the state has a bounded maximum, and the emitted result records the window start, window end, key, and any lateness or recovery caveat.

46.6.1 Under-the-Hood Knowledge Check

46.7 Release Checklist

Before shipping an edge stream window contract, verify these records:

  • Every emitted metric names its window type, window size, slide interval or session gap, key, and clock alignment rule.
  • State has a bounded maximum for each keyed stream, including worst-case device counts and reconnect bursts.
  • Late, out-of-order, duplicate, and replayed events have explicit accept, drop, update, or quality-flag policies.
  • Reboot recovery says whether partial windows are discarded, restored from durable state, or emitted with caveats.
  • Downstream dashboards can see window start, window end, source clock, lateness status, and any aggregation or recovery caveat.

46.8 See Also

46.9 Next

Return to Edge Processing Patterns, then continue to Cyber-Foraging and Caching for opportunistic offload and cache decisions.