skip to content

Windowing

3 roadmaps5 questions

Tumbling, hopping, sliding and session windows, with grace periods and window retention. Comes up whenever aggregation over time is on the table and late-arriving data has to be handled.

part ofApache Kafkaoverview, primer and where to startread it →
on this pageshow

explore

questions

5

What are the four window types in Kafka Streams, and how do they differ?

level: juniorimportance: must knowfreq 78%

answer

  1. Tumbling = non-overlapping buckets
  2. Hopping = size + advanceBy (overlap)
  3. Sliding = ofTimeDifferenceAndGrace (pairwise)
  4. Session = inactivity gap, merges
  5. Tumbling is hopping with advance==size

basics

~10 s

Tumbling (fixed, non-overlapping), hopping (fixed size, overlapping by advance interval), sliding (window around record pairs within a time difference), and session (activity-gap-based, dynamic size). The first three are time-based; sessions are data-driven.

solid answer

~40 s

Kafka Streams has four window types. Tumbling windows are fixed-size and non-overlapping, so each record falls into exactly one window (e.g. 1-minute buckets). Hopping windows are fixed-size but advance by a smaller hop, so they overlap and a record can land in multiple windows (e.g. 5-min size, 1-min advance). Sliding windows (SlidingWindows.ofTimeDifferenceAndGrace) create windows based on record timestamps so two records are in the same window only if their timestamps differ by at most the configured size — used mainly for sliding aggregations and joins. Session windows (SessionWindows) are data-driven: a session grows as records arrive and closes after an inactivity gap; adjacent sessions merge. Tumbling is a special case of hopping where advance == size. All use TimeWindows/SlidingWindows/SessionWindows builders.

go deeper

for a junior

Be able to name the four types and give a one-line distinction (overlap vs not, fixed vs variable).

for a middle

Know the builder classes (TimeWindows, SlidingWindows, SessionWindows) and that tumbling == hopping with advance==size.

for a senior

Explain time-based vs data-driven boundaries, why sliding beats tiny hopping windows, and session merging on out-of-order data.

for a principal

Reason about state/output amplification from overlapping windows and choose window type by workload (billing buckets vs user sessions vs anomaly detection).

## What is windowing? A **window** groups records by time so you can compute aggregates over bounded slices of an unbounded stream (counts, sums, etc.). Without windows, an aggregation over a stream would accumulate forever. Windowing turns "count all clicks" into "count clicks per minute". Kafka Streams offers **four** window types: ### 1. Tumbling windows Fixed size, **non-overlapping**, gapless. Each record belongs to **exactly one** window. A 1-minute tumbling window produces buckets [00:00,00:01), [00:01,00:02), … Built with `TimeWindows.ofSizeAndGrace(Duration.ofMinutes(1), grace)`. ### 2. Hopping windows Fixed **size** but **advance** (hop) by a smaller interval, so windows **overlap**. A 5-minute window advancing every 1 minute means each record falls into up to 5 windows simultaneously. Built with `TimeWindows.ofSizeAndGrace(size, grace).advanceBy(advanceInterval)`. **Tumbling is just hopping where advance == size** (the default when you don't call `advanceBy`). ### 3. Sliding windows `SlidingWindows.ofTimeDifferenceAndGrace(maxDiff, grace)`. Windows are defined **relative to record timestamps**: two records are aggregated together only if their timestamps differ by at most `maxDiff`. New windows are created at record boundaries, so windows are as numerous as needed but each is exactly `maxDiff` wide. Far more efficient than emulating the same behavior with tiny hopping windows. Used for sliding aggregations (added in KIP-450). ### 4. Session windows `SessionWindows.ofInactivityGapAndGrace(gap, grace)`. **Data-driven**, **variable size**. A session keeps growing as long as records keep arriving within `gap` of each other; when a gap larger than `inactivityGap` occurs, the session closes. Out-of-order records can cause two existing sessions to **merge** into one. Great for user-activity / clickstream analysis. ## Time-based vs data-driven Tumbling, hopping, and sliding windows have boundaries derived purely from the clock/record timestamps and a fixed size. Session windows have boundaries derived from the **data distribution** (where the gaps are), so two different keys can have completely different session boundaries. ## Edge cases - A record's window membership is decided by its **event-time timestamp** (the timestamp extractor / `TimestampExtractor`), not wall-clock arrival. - Overlapping windows (hopping/sliding) multiply the amount of state and the number of output rows per record. - Session windows are the only type where windows can shrink/grow/merge retroactively as late data arrives within grace.

  • How is a tumbling window related to a hopping window in the API?
    A tumbling window is a hopping window where the advance interval equals the window size. If you build a TimeWindows and never call advanceBy(), you get a tumbling window by default.
  • Which window type produces variable-length windows and why?
    Session windows. Their boundaries are data-driven by inactivity gaps, so each session lasts as long as records keep arriving within the gap; late out-of-order records can even merge two sessions.

saying these in an interview costs you the question

  • Saying tumbling windows can overlap (they cannot — that's hopping)
  • Claiming all window types are fixed size (sessions are variable)
  • Confusing sliding windows with hopping windows of small advance
  • Saying window membership is decided by arrival/wall-clock time rather than event-time timestamp

context

resolving links…

open as a page

What is the grace period in Kafka Streams windowing (ofSizeAndGrace), and what happens to records that arrive after it?

level: middleimportance: must knowfreq 72%

basics

~20 s

The grace period is extra time after a window's end during which late (out-of-order) records are still accepted and update the window's result. Once stream time passes window-end + grace, the window is closed and later records are dropped.

open as a page

How do JoinWindows work in a KStream-KStream join, and what does the window size mean?

level: seniorimportance: should knowfreq 58%

basics

~20 s

JoinWindows define how close in event time two records from the two streams must be to join. With JoinWindows.ofTimeDifferenceAndGrace(d), records join if their timestamps differ by at most d (symmetric: a within [b-d, b+d]). Each stream is buffered in a window store for that span.

open as a page

How do session windows work, including session merging and the inactivity gap?

level: seniorimportance: should knowfreq 50%

basics

~20 s

A session window groups records for a key that arrive within an inactivity gap of each other. The window grows with each new record and closes when no record arrives for longer than the gap. Out-of-order records can merge two adjacent sessions into one.

open as a page

How are windowed aggregation results keyed and stored — explain Windowed keys, windowed serdes, and the segmented store layout?

level: principalimportance: should knowfreq 40%

basics

~20 s

A windowed aggregation produces a KTable keyed by Windowed<K> (the original key plus the window's start/end). It is stored in a segmented WindowStore (RocksDB split into time segments) and serialized with a WindowedSerdes that encodes key + window timestamp. Old segments are dropped wholesale when they fall outside retention.

open as a page