When each arriving order is enriched from a reference table, what supplies the bound for the computation and when is a result emitted?

## The one computation here with no interval This category exists because an endless input supplies no boundary of its own. An aggregate has to be given a **grouping interval** - a span of time whose records produce one result. A match between two endless inputs has to be given a **match bound** - a limit on how far apart the two records' moments may be, which is the only thing that lets either side stop being held. An enrichment against a reference is the third case and it has neither of those. Nothing is grouped, nothing is accumulated, and no boundary is chosen by the author at all. What bounds it instead is a property of the reference: a **validity span**, the period over which one particular version of a reference row is the correct one. A reference that keeps its history stores one row per key *per span*, each carrying the moment the version took effect and the moment it stopped being in force. The arriving record carries its own moment - the moment stamped by the source when the thing actually happened - and that moment falls inside exactly one of those spans. That is the version the record may see. ## What is emitted, and when Because there is no group, there is nothing to declare finished. The shape is one output per input record: - **No interval closes.** An answer that says "the enrichment emits when the window closes" has imported an aggregate's mechanics into a join that has no window in that sense. - **No fan-out.** One record does not land in several results the way a record in overlapping intervals does; it matches one version per key. - **Nothing is dropped for lateness by the join itself.** A record that arrives long after its moment still has a moment, and that moment still falls inside a span. What can go wrong is that the copy of the reference no longer remembers that span - which is the failure this leaf is really about. - **The output is emitted once the match can be resolved**, which is usually at once and is not always at once. That last qualifier is the honest part. Three things delay it, and which of them applies depends on how the local copy is kept current: a periodic reload means the record simply matches whatever the copy last loaded; a feed of the reference's committed changes means the job can choose to hold the record until that feed has advanced past the record's moment, using the job's running assertion that nothing older is still to arrive; a lookup per record means the output waits on a round trip to the reference store. ## Which clock the moment is read on A bound is only as definite as the clock it is measured on. There are two: the moment stamped by the source when the thing happened, and the moment a worker reached the record. An enrichment that silently uses the second one is not doing an as-of match at all - it is asking "what was true when I got round to this record", which is a different question and gives different answers on a re-run. A complete answer therefore *says which clock it assumes*. How a clock is chosen, and how the running completeness assertion advances, are owned elsewhere in this tree and are relied on here, not re-argued. ## Two shapes of the same join | | grouping interval (an aggregate) | validity span (this join) | |---|---|---| | who supplies the bound | the author, as a length | the reference, as a per-version period | | what is held | the records or accumulator of each open group | one row per reference key per span, for the life of the job | | when output appears | when the group is declared finished | per input record, once its match resolves | | how many outputs per record | one per group it belongs to | one | | what makes it finite | the interval ends | the record's own moment picks one version | ## What varies between engines, and what does not The rule above is common to the whole class. The mechanics around it are not, and a candidate who states one engine's behaviour as the law is the thing interviewers here are listening for: 1. **When the match is evaluated.** Some runtimes advance one record at a time through long-lived operators, so a new reference version can take effect between two consecutive records. Others collect arrivals for a short span and run one finite job over the collected set, so the copy is effectively frozen for the width of that span. The oldest model in this family does not maintain anything between runs at all - a "refresh" there means the next run reads the reference again. 2. **Where the held copy lives** - in the worker's own memory, in an on-disk structure beside it, or nowhere, because the job looks the value up each time. Engines differ, and where it sits is a different subject with its own owner. 3. **Whether the job can wait for the reference feed.** Holding a record until the change feed has passed its moment is available where the runtime can defer individual records; it is awkward where the unit of progress is a collected span. ## What an interviewer is listening for A strong answer names the bound without being led to it ("the record's moment against the version's validity span"), states which clock it assumes, and says that one record yields one output rather than waiting for anything to close. A weak answer reaches for a window because the input is a stream, or assumes the join always sees whatever row is current at the moment the job runs.