A job folds one small value per group, yet runs out of room — which two quantities multiply to set that memory, and what inflates each?

## The memory of a grouping is a product The number that decides whether a grouping job runs is not the interval's length and not the arrival rate on its own. It is: > retained memory is approximately **what one open group holds** multiplied by **how many groups are open at the same time** Candidates reliably reason about the first factor and forget the second, which is how a job with a four-byte counter per group runs out of room. Both factors have to be estimated before the job is written, because only one of them is easy to change afterwards. ## Factor one: what one open group holds - A **foldable accumulator** — a per-group value that any two of which merge into one and that does not grow with records folded in — is a constant: one number, or a small tuple such as a total and a count. - A **retained record set** grows with the records the group has seen, so this factor becomes arrival-rate-dependent and the product becomes a triple. - The grouping key itself is usually stored per open group alongside the value, which matters when the key is a long string rather than an integer. - How a carried value is laid out in bytes is a separate subject from this one; estimate it as a plausible per-group figure and be explicit that it is an estimate. ## Factor two: how many groups are open at once - **Distinct grouping keys active in the period.** This is usually the dominant term and it is usually supplied by the data, not by the author: user identifiers, device identifiers, session identifiers. - **The overlap factor.** An interval of length L restarted every step S shorter than L means any instant is covered by L divided by S intervals, so one key has that many groups open simultaneously and each record is folded into all of them. - **Groupings with no fixed length.** A grouping that stays open for one key while records keep arriving, and closes after a stated quiet period with none, keeps one group open per key that has been active recently — and its length is a property of the data. - **Residency after the span ends.** A group is not droppable the moment its span is over. It waits for the job's running assertion that no record older than a stated moment will still arrive, and it may then wait through a further stated span during which it still accepts records and re-emits a corrected value. Both extend how many groups coexist. - **Anything that never expires.** A grouping over a key space that keeps producing new keys accumulates groups for as long as nothing drops them. ## Worked arithmetic 1. Distinct keys active in an interval: two million. 2. Interval length fifteen minutes, restarted every minute, so the overlap factor is fifteen. 3. Open groups: two million times fifteen, which is thirty million. 4. Carried value estimated at 48 bytes: thirty million times 48 bytes is about 1.4 gigabytes — with not one record retained. The instructive part is which step you can move. Dropping the overlap factor from fifteen to three, by restarting the interval every five minutes instead of every minute, divides the answer by five and changes the product's output resolution, which is a requirements conversation. Coarsening the grouping key divides it too, and changes what the result means. Shrinking the carried value by a few bytes changes almost nothing, which is why tuning it is the wrong instinct. ## What the number is for, and where this subject stops This arithmetic is a design-time argument: it tells you whether the grouping as specified is viable, and which of the two factors to negotiate if it is not. What the runtime does when the total exceeds what a worker can hold — writing part of it to local disk, failing, or degrading — and where those bytes physically sit are separate subjects with their own owners. So is how one worker's memory is divided between competing uses. Compute the product, compare it against what the job has to work with in total, and hand the overflow question to the people who own it. ## Where engines of this class differ - **How the open groups are maintained.** Where each record advances individually through long-lived operators, the open groups live continuously for as long as they are open. Where arrivals are instead collected for a short span and one finite job runs over the collected set, the carried values are handed from one such job to the next, so the same product applies but residency is counted in whole spans. In a finite pass that materialises between phases there are no groups open between runs at all, and the product applies only within one pass. - **Whether the open-group count is under the author's control.** Sometimes the width of the job and the key space can be changed while it runs; in other designs the width is fixed for the life of the job, so the only lever left is the grouping key or the boundary. - **What bounds the count.** Some runtimes will drop a group's carried value once a stated span has passed with no write to it; others leave that entirely to the author. Never assume a ceiling exists because one runtime you used provided one.