Stream Window Aggregator: Tumbling vs Sliding

Windowing

Window size 4.0 s

Slide step (sliding only) 1.0 s

Stream rate 12 ev/s

Events counted

–

Window avg

–

Dropped (late)

–

Sim clock

–

How it works

Big data's "Velocity" V means records must be aggregated while they are still arriving, not after the fact. Stream engines solve this with windows: fixed spans of event time over which an aggregate (here, the mean of each event's value) is computed. A tumbling window fills up, closes and flushes exactly once — the box on the belt grows from nothing to full width, then snaps back empty for the next span. A sliding window instead always covers the last W seconds and re-emits its aggregate every step seconds, so consecutive windows overlap when step < W.

bucket(t)   = floor(t / W)          // tumbling: one aggregate per bucket
active(t)   = [t − W, t]            // sliding: recomputed every `step`
watermark   = window_close_time      // late arrivals after this are dropped

Events are generated as a genuine Poisson process — inter-arrival time = −ln(U)/rate for U~Uniform(0,1) — so the gaps between arrivals are random even though the average matches the "Stream rate" slider. A fraction of events are deliberately delayed before they reach the aggregator, modelling network jitter and out-of-order delivery (the "Veracity" V): if a delayed event's window has already closed by the time it arrives, it can no longer be counted and is flagged as dropped instead — exactly the trade-off real systems like Flink or Kafka Streams make when choosing a watermark/allowed-lateness bound.

Window size — how many seconds of the stream each aggregate covers; larger windows smooth out noise but react more slowly.
Slide step — sliding mode only: how often a new (overlapping) aggregate is emitted. Small steps look almost continuous; step = window size degenerates into tumbling.
Stream rate — average events per second; higher rates fill windows faster and raise the odds a delayed event misses its watermark.

Real-world relevance: this is the same tumbling/sliding choice engineers make when building dashboards over clickstreams, IoT telemetry or fraud-detection pipelines — get the window and lateness bound wrong and you either report stale numbers or silently drop good data.

Counted event In flight (delayed) Dropped (missed watermark)

⚠ Couldn't load the 3D engineThree.js failed to load from the CDN. Check your connection and reload.