Which parts of a job's logic cannot be lifted into a plain function, and what do you do about them?

## Rules lift; compositions do not The separation that makes a distributed job testable has a boundary, and knowing where it falls is what distinguishes a candidate who has done this from one who has read about it. **Lifts into a plain function:** - the mapping from a record to the value it is grouped by; - the predicate that keeps or drops a record; - the derivation that turns fields into fields; - the merge of two partial values into one; - for a step that carries a retained set - everything a long-running job still holds between records, such as counters, buffered sides of a join, or the last value per key - the transition function taking the old retained set and one record and returning the new retained set plus whatever it emits; - the shaping of the final output record. **Does not lift, because it is arrangement rather than meaning:** - **which records meet.** Records that must be compared to each other have to be held by the same worker, which means a redistribution: the point where a step needs records currently held by other workers, so every worker writes its records out and every worker fetches the ones addressed to it. Whether your key produces the grouping you intended is a property of that arrangement. - **how many times a merge runs, and where.** Runtimes differ: some apply a partial merge on each worker before records meet, some do not, some decide at run time. The function must tolerate whichever, and a test that calls it once has only proved the single-call case. - **the order pieces arrive in** at the step that combines them, which is not yours to choose. - **what a declared join does** with a key that has no match on the other side, since that behaviour is the runtime's, not your function's. - **whether the retained set you wrote is the one you get back** after a restart, a code change or a change of width. The algebra a partial merge must satisfy for the result to be independent of how the work was split is the parallel-reduction pattern's subject (the parallel-reduction pattern). Here the point is narrower: the merge is a callable function, while the schedule of its applications is not. ## The wiring wants to be boring The untestable surface is not fixed - it grows every time a business rule is typed into the wiring. Three common leaks: 1. A filter condition written inside a declared join instead of as a predicate. 2. A special case for one customer expressed as an extra branch in an output declaration. 3. A cutoff date typed into a grouping or partitioning declaration rather than passed in. Each of those can only be exercised by running the job. Move them out and the wiring reduces to locations, declarations and references to lifted functions - arrangement with no meaning in it. ## Making a stateful step liftable A long-running step is the case people give up on, and it is the most rewarding one. Write the logic as a pure transition: - input: the retained set as a plain value, plus one record; - output: the new retained set, plus zero or more emitted records. That function is testable as a *sequence*: feed it ten records in order and assert on both the emissions and the retained set at each point, including the ones that should expire something. What the test still cannot prove is that the runtime hands you the retained set you last returned - after a restart, after a width change, after a code change - because that is the runtime's contract and it differs between them. ## The residue, stated honestly | fragment | liftable | what still needs a run | |---|---|---| | record to grouping key | yes | whether that key spreads records the way you assumed | | predicate, derivation | yes | nothing, if it is genuinely per-record | | merge of two partials | yes | how many times it is applied and on which worker | | retained-set transition | yes | that the runtime returns the set you wrote, across restarts | | join semantics for a missing match | no | the declared behaviour, on real inputs | The answer an interviewer is listening for has both halves: the list of fragments you pulled out and tested, and the short, specific list of what is left - not a shrug about integration testing.