Joins and windows over unbounded streams

Filtering or reshaping one event at a time needs no memory. Counting clicks per five-minute window, joining orders with payments, or keeping a running balance per account does: the processor has to keep state, partitioned by key, for as long as the computation needs it. Events also arrive late and out of order, so a window over event time has to wait for a watermark that says no older events are expected before it emits a result.

To tell whether a system really handles it, look at where it keeps state (memory, local RocksDB, remote storage) and how large that state can grow, how it snapshots state so a crash resumes without losing or double-counting events, and whether it reads event time and watermarks or only the wall clock. Exactly-once results need both consistent snapshots and a source that can replay from a position, such as a Kafka offset, plus a sink that can take transactional or idempotent writes.