Over an endless input, what three ways can a grouping boundary be defined, and what sets each group's extent?

## Why a shape is needed at all An endless input never ends, so nothing computed over it finishes on its own. A count, a sum, a maximum or a distinct cardinality is defined over a **finite collection**, and a continuous feed of records is not one. Every aggregate over such an input therefore starts by inventing a boundary: a rule that decides which records belong together and yields one value for that set. The three shapes below are the three rules in general use, and they differ on exactly one axis — **what sets a group's extent**. Two decisions are *not* part of the shape and are separate subjects: which of the two available moments the boundary is read against — the moment the pipeline assigned from the record itself, or the moment the worker reached it — and at which points a group's current value is handed downstream. A shape is fully stated without answering either. ## Back-to-back spans of equal length The timeline is cut into adjacent intervals of one stated length, each half-open so that a moment on a boundary belongs to one side only. - The extent comes entirely from the **definition**: state the length and every group's extent is known before a single record arrives. - One record contributes to **exactly one** group, so the groups form a partition of the input. - The number of results per grouping key is the elapsed time divided by the length. - An interval into which no record's moment falls still exists by definition; whether a job actually emits a zero-valued row for it **varies between engines**, and a report that needs a complete grid usually fills the holes itself. This is the shape behind phrasings like *per calendar minute*, *hourly totals*, *the daily count*. Its borrowed name is the tumbling window. ## Fixed-length spans restarted every step Here two numbers are stated: a length and a restart step shorter than that length. A new span begins every step, so spans overlap. - A record's moment lies inside every span that started within one length before it, so membership is **length divided by step** — ten-minute spans restarted every two minutes put each record in five groups. - When the step does not divide the length evenly the count is that ratio rounded up or down, so neighbouring records can differ by one. - The output volume multiplies by the same factor: five times as many results as equal spans of the same length. - A step equal to the length collapses the shape into back-to-back spans; a step **longer** than the length leaves gaps, so some records fall in no group at all — rarely wanted, but worth naming when a requirement implies it. This is the shape behind *the last hour, refreshed every minute*. Its borrowed name is the sliding window. ## Groups the data closes itself The third shape states no length. A group opens for one grouping key when a record for that key arrives, stays open while records keep arriving, and closes once a stated quiet period elapses with none. - The extent is a property of the **arrivals**, not of the definition, so it is unknown until the group has closed. - Groups are per key and unequal: one key's group may last nine seconds and another's nine hours. - A key that never goes quiet keeps its group open indefinitely, which is why a stated maximum extent is usually layered on top. This is the shape behind *per visit*, *per trip*, *per support conversation*. Its borrowed name is the session window. ## The three side by side | shape | extent set by | one record belongs to | extent known in advance | sits on a common grid | |---|---|---|---|---| | back-to-back equal spans | the definition | exactly one group | yes | yes | | fixed length restarted every step | the definition | length divided by step groups | yes | yes, several at once | | gap-closed grouping | the arrivals | one group per key, once bridging is settled | no | no | ## What varies between runtimes The shapes are the same everywhere; how finely they can be placed is not. 1. A runtime that advances by collecting arrivals for a short span and running one finite job over the collected set cannot place a boundary **finer than that span**. 2. A record-at-a-time runtime, where each arrival moves through long-lived steps that carry values between records, can update a group at the granularity of one record. 3. The oldest model in this class, a finite two-phase pass that writes its intermediate result to disk, maintains no open group at all: a shape there is a grouping expression inside a re-run over a finite slice of history. 4. Whether the overlapping shape is implemented by assigning the record to each covering group or by keeping partial values that are combined later also varies — and changes none of the arithmetic above. ## Reading a requirement onto a shape - *per calendar hour*, *daily* — back-to-back equal spans. - *the last fifteen minutes, updated every minute* — fixed length with a restart step. - *per visit*, *until the user goes away* — gap-closed. - *right now, continuously* — possibly no interval at all, just a running value per key, which is the honest answer often enough to be worth offering.