Hopping Windows
Parent: MongoDB Atlas Stream Processing · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-40309c756b09
↓ Facts as markdownall context files
Source-anchored research for Hopping Windows. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
Definitions
- Cross-platform hopping-window semantics are not interchangeable: Microsoft documents Azure defaults as start-exclusive and end-inclusive, while the Atlas sources reviewed here do not establish that same endpoint convention. Do not copy Azure endpoint assumptions into Atlas pipelines. (medium confidence) [source]
Structure and components
- Atlas implements hopping aggregation with $hoppingWindow: interval specifies duration, hopSize specifies spacing between starts, and pipeline contains the aggregation stages evaluated over each window. (high confidence) [source]
- A five-minute interval with a thirty-second hop can compute per-sensor rolling averages using a nested $group and $avg. Thirty seconds is the nominal spacing between windows; it is not a wall-clock output guarantee. (medium confidence) [source]
How it works
- An idle source can prevent event-time windows from closing while the watermark waits to advance. Atlas offers idleTimeout to mitigate this; the architecture page also identifies idle Kafka partitions as a potential cause and points to partitionIdleTimeout. (high confidence) [source]
Problems, failure modes and limitations
- Atlas documents eventTime as the default hopping-window boundary and supports processingTime as an alternative. Processing-time assignment uses the processor server clock; idleTimeout and allowedLateness cannot be configured for that boundary. (high confidence) (verified as of 2026-10-14) [source]
- MongoDB's stage reference documents one window stage per pipeline and a 100 MB RAM limit per $group key. These constraints matter when sizing overlapping aggregations. (low confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- A useful Atlas pattern is a five-minute average with a 30-second hop: aggregate the latest five-minute interval at each window closure, rather than compute disjoint five-minute summaries. (high confidence) [source]
Facts and statements
- Atlas hopping windows use interval for window duration and hopSize for the spacing between window starts. If hopSize is smaller than interval, windows overlap and the same event can contribute to several window aggregates. (high confidence) [source]
- $hoppingWindow requires interval, hopSize and a nested pipeline. The duration and hop accept positive integer sizes with ms, second, minute, hour or day units. (low confidence) [source]
- Place blocking aggregation stages such as $group and $sort inside the hopping window's pipeline. Stateless stages such as $match and $project can operate before the window. (high confidence) [source]
- For event-time hopping windows, allowedLateness delays closure relative to the watermark; it does not prevent subsequent windows from opening. Events arriving after their window has closed can be routed to a configured dead letter queue. (high confidence) [source]
- Kafka partitions that stop advancing event time can stall window output. The architecture documentation recommends partitionIdleTimeout at the source to prevent idle partitions from blocking watermark progression. (low confidence) [source]
- A public MongoDB incident investigation, [redacted], used a one-hour hopping window with a one-second hop for Wikipedia-comment word counts and reported pod out-of-memory behavior. It was closed as a duplicate of [redacted] in August 2024; it does not establish a current unfixed defect. (low confidence) [source]
- Do not transfer exact timestamp-edge rules from another engine: MongoDB's worked window example includes the start timestamp and excludes the end, whereas Azure Stream Analytics hopping windows default to excluding the start and including the end. (high confidence) [source]
- MongoDB's example groups results by {$meta: 'stream.window.start'} and writes them with $merge, allowing each hopping window's result to retain its window identity. (low confidence) [source]
- The January 20, 2025 changelog explicitly records a fix permitting hopping-window hopSize greater than interval. This conflicts with the windows overview's statement that the hop must not exceed the interval. (high confidence) [source]
- MongoDB's Stream Processor Windows overview says a hopping window's hop must not exceed its interval and gives a 20-second interval with a 5-second hop, which overlaps adjacent windows by 15 seconds. The Atlas Stream Processing Changelog records a January 20, 2025 fix for an issue that prevented configuring hopSize greater than interval; the official references therefore conflict about that bound. (low confidence) [source]
- Overlapping results reuse events by design. Summing counts from successive overlapping windows would count some input events more than once; applications seeking unique totals must account for this overlap. This is a consequence of the documented membership model. (high confidence) [source]
- For Atlas event-time hopping windows, allowedLateness delays closure relative to the watermark. It keeps an earlier window open without preventing later windows from opening; it is not a promise to reopen an already closed window. (high confidence) [source]
Children
- No children recorded.