A job is slow and its runtime publishes no per-step blocked-time figure. Which other signals identify the bottleneck, and when does backpressure not exist at all?

## Why the figure may be missing The engines in this family instrument themselves differently, and a candidate who has only used one tends to assume the whole class publishes the same thing. Some runtimes measure the handover between steps directly and publish a blocked-time fraction or a busy/idle split per step. Others publish only per-step throughput and the occupancy of the queues between steps. Some publish neither, and you are left with elapsed times and resource counters. None of that changes the mechanism — **backpressure**, a step that cannot accept records stopping the step that feeds it — only the evidence you have for it. ## Substitutes, in the order worth trying 1. **Buffer occupancy per handover.** This is the most direct proxy. Behind the constraint the queues are full; after it they are empty, because the constrained step consumes everything it is given and the steps after it are starved. The boundary between a full queue and an empty one is the constrained step. 2. **Processed throughput per step, in records per second.** In a settled graph every step processes at the same rate, so the numbers alone prove nothing — this is the trap. What distinguishes the constraint is that it achieves that rate while working continuously, whereas its predecessors achieve it while idle much of the time. Pair the rate with any available busy or CPU figure and the boundary appears. 3. **The read rate from the source against the rate at which input arrives.** A throttled read is the last link in the propagation chain. If the job is reading more slowly than input is arriving, and the read step is not itself the expensive one, something further along is holding it back. 4. **Elapsed time per step or phase.** In a model where steps do not overlap, this is not a proxy at all — it is the answer. ## The experiment that settles it Signals are inference; a controlled change is evidence. Two cheap ones: - **Replace the destination with a discard.** Run the same logic writing nowhere. If the rate jumps, the destination or the write step was the constraint; if it does not move, the constraint is inside the graph. - **Run over a fixed finite input.** This removes any variation in what arrives and makes two runs comparable, which is what lets you attribute a change to the thing you altered rather than to the day. Neither is free — a discard run still consumes cluster capacity, and a finite input cannot reproduce everything about a continuous one — but both convert an argument into a measurement. ## Where the question does not apply This is the part that catches people who generalise from one engine. | Execution model | Is there in-flight resistance? | What you read instead | |---|---|---| | Record-at-a-time processing with key-bound state | Yes. Records cross between live steps continuously, so a slow step blocks its producer directly. | Blocked fraction or buffer occupancy per step. | | A continuous job built from repeated small finite runs — the engine slices an endless input into small finite jobs run back to back | Partly. Resistance inside one slice is brief and often not surfaced. | Each slice's duration against the period it covers, and which step dominates that duration. | | The two-phase disk-to-disk model — every phase writes its whole output to shared storage before the next phase reads it | No. Nothing is in flight between phases, so there is no producer to block. | The elapsed time of each phase, and how long the slowest piece within it took. | Saying this out loud is worth more in an interview than any list of signals, because it shows you are describing the class rather than the one engine you happen to know. The generic sentence is: *backpressure is a property of a live handover between two concurrently running steps; where the handover is a write to shared storage that completes before the reader starts, there is no handover to resist.* ## One more place it does not appear Even in a live graph, there is no resistance to see when the constraint is the **first** step. A step only blocks when it has somewhere to push back to, so a slow read from the source — or a source that simply supplies slowly — produces a calm graph and a job that is nonetheless not keeping up. That is why the read rate belongs on the list of substitutes and why a completely quiet set of figures is never, by itself, evidence of health. ## Putting it together The answer an interviewer is listening for has three parts: name the mechanism independently of any screen; name two or three substitutes and say what pattern in them locates the constraint; and name at least one model in which the question dissolves because there is no live handover. A candidate who gives only the first engine's dashboard has answered for one product and not for the class.