Your batch jobs lean on runtime re-planning around uneven pieces, and the same logic must now run continuously over an endless input - what coverage is lost, and how do you plan around it?

## Why the correction disappears **Runtime replanning** is the engine re-deciding part of the plan it has not run yet, using the sizes a finished step actually produced. Every word of that depends on completion: a step ends, its output is countable, and a later step has not started. A job over an endless input breaks the first link. There is no last record, so no step finishes in the sense the mechanism needs, and therefore no measured output to re-plan from. This is the leaf's sharpest consequence, and it is the one candidates most often get wrong in the optimistic direction - assuming the runtime notices a heavy piece and deals with it, when in the continuous case it largely cannot. ## But say which continuous design you mean The engines in this class genuinely disagree, and an answer that treats 'continuous' as one thing is wrong about half the market. | design | is there a finished step to measure? | what re-planning can do | |---|---|---| | continuous work run as a rapid succession of small finite jobs | yes, inside each small job | the same corrections can fire within one small job, on that small job's own measured sizes | | a record-at-a-time runtime pushing records onward as produced | no; nothing is materialised between steps | essentially nothing; there is no measurement to act on | Even on the first design the help is thinner than it looks. What persists across the small jobs is what matters for uneven work: the width the job runs at, the key-to-destination rule, and any long-lived state bound to a key. A heavy key is therefore heavy in every single small job, and a correction rediscovered and reapplied each time is not the same thing as fixing the cause. On the second design the situation is starker - the reason its recovery, its latency and its handling of uneven work are all different subjects is that it never materialises an intermediate result at all. ## What moves, and where it moves to Losing the correction does not lose the problem; it relocates the decisions. Three of them move earlier: 1. **Width and shape become design-time commitments.** In a continuous job, the number of parallel instances is usually fixed for the life of the job, and changing it means stopping and restarting with the state redistributed - not a mid-run adjustment. You choose once, in advance, with no measurement. 2. **Sizing is for the worst key, not the average.** With no correction to lean on, the instance that owns the heaviest key sets the job's throughput. Capacity has to be provisioned for that instance rather than for the mean, which is a real and permanent cost. 3. **The key itself becomes the leverage.** If unevenness is structural in the data, the durable fixes are upstream or in the job's own design - and they are the author's, applied deliberately, rather than something the runtime will discover. ## How you see the problem at all The evidence changes too. In a finite job you read what each completed unit produced. In a continuous job nothing completes, so the signal is **backlog** - how far behind the newest available record each piece currently is - watched per piece rather than in aggregate. A mean backlog hides the one instance that is falling permanently behind, which is exactly the instance a heavy key creates. Reading that distribution is its own skill and its own subject; the point here is that your evidence is a live per-piece measure instead of a completed-step report. ## The argument to make to a team When a team proposes moving established finite work onto an endless input, the honest framing is a trade: - **What you buy**: results that track the input instead of arriving on a cadence. - **What you pay**: an automatic correction for uneven work that was quietly doing real operational work for you, and the ability to change the job's shape without stopping it. - **What that implies**: unevenness must be handled explicitly and in advance, capacity is provisioned for the worst key, and any change of width or key is scheduled as a restart from a recovery point rather than absorbed while running. There is no universally right answer - that is why this is a judgment call rather than a fact. The failure mode to avoid is deciding on latency alone and discovering afterwards that the uneven key which was invisible in the finite version, because the runtime kept absorbing it, is now a permanent ceiling on throughput. ## What a strong answer sounds like It states the mechanism ('the correction is fed by completed measurements'), it distinguishes the two continuous designs instead of generalising from one, it names what persists across small jobs, and it converts the loss into concrete commitments - width chosen up front, capacity sized for the heaviest key, changes scheduled as restarts, evidence read as per-piece backlog. A weak answer either asserts that the runtime will handle it anyway, or asserts that continuous jobs get no help at all - both are overstatements of a model that is genuinely split.