An unbounded stream has no end, so you can't sum it — you cut it into windows, and how you cut it decides what the number means.
You can't total an infinite queue, so you count in five-minute slices — or in visits, which start and end when the person does.
The window shape decides both what the number means and whether the job stays inside its memory budget.
You cannot aggregate an infinite stream; you can only aggregate finite slices of it. Tumbling windows are fixed, non-overlapping buckets — hourly revenue, one row per hour, every event counted once. Sliding windows overlap — a five-minute count emitted every minute — so each event lands in several windows and the series is smooth enough to alert on. Session windows have no fixed size at all: they group events separated by less than a gap timeout, which is how you measure a user's visit rather than an arbitrary clock interval. Each shape holds state per key per open window, and that state is the thing that decides whether the job stays up.
Tumbling windows are fixed and non-overlapping — each event counted once, ideal for reporting periods. Sliding windows overlap, so each event lands in several and the metric moves smoothly, at the cost of more state. Session windows close after a gap of inactivity, which is how you measure a visit. State grows with keys times open windows, so the window shape is a memory decision as much as a semantic one.
(17) Time Windows in Fabric Streaming | Tumbling, Hopping, Sliding, Session & Snapshot | DP-700 Exam — Raghu Veer Tech, 7:20