Tumbling 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 Tumbling 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
- Periodic per-key sensor summaries are a practical Atlas pattern: group measurements inside each window and compute averages, minima and maxima. A public smart-grid demo uses daily tumbling windows, while MongoDB's tutorial illustrates minute-scale rollups. (medium confidence) [source]
Structure and components
- For event-time tumbling windows, interval duration alone does not establish wall-clock output latency. Watermark progress controls closure, and allowedLateness delays closure relative to that watermark while permitting newer windows to open. (high confidence) [source]
- Non-overlap describes window membership. It does not establish exactly-once end-to-end delivery, guarantee inclusion of arbitrarily late events, or guarantee an output every interval of wall-clock time. (medium confidence) [source]
How it works
- Atlas supports event-time and processing-time boundaries. Event time uses document timing; processing time uses the server clock when the processor consumes a document. A delayed event can therefore fall into different windows under the two modes. (high confidence) [source]
- An idle source can leave an event-time window waiting for watermark progress. Atlas provides idleTimeout to allow windows to close during source inactivity; the stage reference and architecture guide disagree about exactly when its timer begins. (high confidence) [source]
Problems, failure modes and limitations
- Atlas defaults boundary to eventTime. When boundary is processingTime, idleTimeout and allowedLateness cannot be configured. (medium confidence) (verified as of 2026-10-14) [source]
- A record that arrives after its Atlas window closes cannot be assumed to update that aggregate. MongoDB documents routing late-arriving documents to a dead letter queue when one is configured. (high confidence) [source]
Comparisons and alternatives
- With a Kafka source, Atlas waits for all partitions to pass the watermark. An idle partition can prevent windows from closing or producing results; the architecture guide recommends the source option partitionIdleTimeout. This differs from the window-level idleTimeout option. (high confidence) (verified as of 2026-10-14) [source]
- Atlas supports only one window stage per stream processor pipeline, and a single $group key inside a window has a documented limit of 100 megabytes of RAM. These are Atlas implementation limits rather than properties of the tumbling-window model. (low confidence) (verified as of 2026-10-14) [source]
Facts and statements
- Tumbling windows partition time into fixed-duration, contiguous intervals without overlap. Each event timestamp maps to one interval; this describes assignment, not a guarantee that arbitrarily late events will be accepted. MongoDB, Apache Spark, and Confluent independently document this window model. (high confidence) [source]
- In Atlas Stream Processing, $tumblingWindow supplies a finite set of streaming documents to its nested aggregation pipeline. This enables per-interval grouping and statistics such as averages, minima, and maxima. (high confidence) [source]
- The Atlas $tumblingWindow stage requires interval and pipeline. interval.size is a positive integer, and interval.unit accepts ms, second, minute, hour, or day. (low confidence) (verified as of 2026-10-14) [source]
- Atlas aligns tumbling boundaries to UTC by default and offers offset to shift them. An offset of eight hours moves the boundaries eight hours ahead of UTC; the documentation does not establish automatic daylight-saving adjustment. (low confidence) (verified as of 2026-10-14) [source]
- The documented default allowedLateness is 3 seconds, and zero can be supplied explicitly. This is a window-closure allowance relative to watermark progress, not a promise to include every delayed record. (low confidence) (verified as of 2026-10-23) [source]
- Late events do not move the fixed time boundaries of a tumbling window. They can change its aggregate if accepted while its state is retained; Atlas allowedLateness delays closure to allow this. (high confidence) [source]
- Atlas preserves stateful window processing through checkpoints. After interruption, a processor resumes from its last committed checkpoint; this does not establish end-to-end exactly-once delivery to every possible sink. (high confidence) [source]
Children
- Watermark-driven window closure (frontier)
- Allowed lateness and late-event routing (frontier)
- Window boundary alignment and offsets (frontier)
- Idle-source and idle-partition handling (frontier)
Frontier under this node: Allowed lateness and late-event routing, Idle-source and idle-partition handling, Watermark-driven window closure, Window boundary alignment and offsets