In a Flink window, why is a ReduceFunction cheaper than a ProcessWindowFunction?

## The two computation models After you have chosen a window assigner, you must attach a **window function** — the code that turns the contents of a window into a result. Flink offers `ReduceFunction`, `AggregateFunction` and `ProcessWindowFunction`, and the difference between the first two and the third is not a matter of API taste. It determines how much state the window operator holds. `ReduceFunction` and `AggregateFunction` are **incremental**. The window operator applies them as each record arrives and keeps only the result so far. `ProcessWindowFunction` is **buffering**: its signature receives an `Iterable<IN>` of the whole window, so nothing can be discarded before the window fires. ## ReduceFunction `ReduceFunction<T>` combines two elements of type `T` into one element of the same type `T`. That same-type constraint is its whole character — it can express a sum, a max, or a "keep the latest" but not an average, because an average needs a running sum *and* a count, which is not the input type. ```java input.keyBy(e -> e.userId) .window(TumblingEventTimeWindows.of(Duration.ofMinutes(5))) .reduce((a, b) -> new Tuple2<>(a.f0, a.f1 + b.f1)); ``` The state for each open window is one `Tuple2`, whether the window received three records or three million. ## AggregateFunction `AggregateFunction<IN, ACC, OUT>` generalises this with three separate types: the input type, an **accumulator** type, and an output type. It has four methods — `createAccumulator()`, `add(value, acc)`, `getResult(acc)` and `merge(a, b)`. The accumulator is free to be a different shape from the input, which is what lets it compute an average (accumulator = sum and count, output = a double), a distinct-count sketch, or a percentile estimate. `merge()` matters specifically for merging assigners: session windows combine two windows by merging their accumulators. Like `ReduceFunction`, the state is one accumulator per open window per key. ## ProcessWindowFunction `ProcessWindowFunction<IN, OUT, KEY, W extends Window>` has a `process(key, context, elements, out)` method. It receives: - the key the window is scoped to, - an `Iterable` of every element in the window, - a `Context` exposing `window()` (with the window's start and end timestamps), `currentProcessingTime()`, `currentWatermark()`, `windowState()`, `globalState()` and `output(...)` for side outputs, - a `Collector` to emit zero or more results. That access is genuinely useful — you cannot label a result with its window's start and end timestamp from a `ReduceFunction`, and you cannot compute a true median without seeing every element. But it costs you: the operator buffers all elements in the window's state, and for a one-hour window over a high-volume key that can be millions of records per key. ## Combining them — the answer interviewers want The framing "incremental *or* full access" is a false choice. Both `reduce` and `aggregate` have an overload that also takes a `ProcessWindowFunction`: ```java input.keyBy(e -> e.userId) .window(TumblingEventTimeWindows.of(Duration.ofMinutes(5))) .aggregate(new AverageAggregate(), new EmitWithWindowBounds()); ``` Flink aggregates incrementally as records arrive, and when the window fires it invokes the `ProcessWindowFunction` with an `Iterable` holding **exactly one** element: the aggregated result. You get the window metadata and per-window state, at one-value-per-window state cost. This combined form should be your default whenever you need the window's timestamps in the output — which is most of the time, because a windowed result stream carries no window information otherwise. ## Per-window state One capability only `ProcessWindowFunction` has is state scoped to *this key and this window instance*, reached through `context.windowState()`, alongside `context.globalState()` for per-key state that outlives the window. It is how you record that a window has already fired once — relevant when a custom trigger fires speculatively or when allowed lateness causes a late firing. Per-window state is not cleaned up for you: you must implement `clear(Context)` to delete it, or it leaks for the lifetime of the job. ## What to say in an interview State the mechanism (incremental fold versus buffered `Iterable`), state the consequence (constant versus linear state per window), name the `merge()` method as the reason `AggregateFunction` works with session windows, and finish by pointing out that the combined `reduce(reducer, processFn)` form removes the tradeoff for the common case. Mentioning `clear()` for per-window state is the detail that separates someone who has read the docs from someone who has operated the job.