Where would you draw the line for permitting unbounded demand in your organisation's stream pipelines?
answer
- the documented opt-out from flow control
- default deny, argue the exception
- name the bound that replaces it
- inline consumer can be the brake
- bounded requests, but not one at a time
basics
~20 sDefault to refusing it, and permit it only where something other than demand already bounds the flow: a source finite by construction, or a consumer that does its work inline so the serialised handover paces the producer. Require the bound to be named, not assumed.
solid answer
~50 sAn unbounded request is a **standing waiver of flow control** between a stage and its source, so the rule should treat it as an exception that must be justified rather than a convenience. Two justifications hold up. First, the source is finite by construction and small — a validated request parameter caps it — so there is nothing to control. Second, the consumer processes each value inline on the delivering worker, in which case the serialised handover itself paces the producer, provided the producer emits on that same worker rather than from its own. Everything else — *it made the code shorter*, *it has not failed yet*, *something downstream will buffer* — is the waiver taken without the argument. The rule's own cost is chatter, so pair it with a sane minimum batch size rather than demanding one-at-a-time requests everywhere.
go deeper
Know that asking for an unlimited number of values is allowed and that it means the producer may send everything at full speed. It is a choice with consequences, not a default.
Explain what the waiver removes and what has to replace it: a source that is finite by construction, or a consumer whose inline processing paces delivery through the serialised handover.
Show the judgment in a real pipeline — spot the stage that quietly opted out, say what bound was supposed to replace demand, and insist on bounded requests wherever data crosses a process boundary.
Own the default and its cost. Default deny with a named alternative bound, mandatory bounds at boundaries, a minimum batch size so the rule is not chatty, and scaffolding that makes the bounded path the easy one.
## What the waiver actually is A consumer may ask for an effectively unlimited count of values. It is a legal move in the protocol and it has one consequence, stated plainly: between that stage and its source there is now **no flow control at all**. The producer is permitted to deliver everything it has as fast as it can, forever. Whatever keeps the system upright from that point must come from somewhere other than demand. That is why this is a policy question rather than a coding question. Any individual pipeline can be argued either way in review; what a lead owns is the default, the shape of the exception, and what evidence the exception has to produce. ## Where the waiver is defensible **The source is bounded by construction.** A ledger export for one account, for one month, where the row count is capped by a request parameter validated at the edge, has nothing to control. The bound exists; it is just enforced upstream of the stream rather than inside it. The reviewable version of this argument names the cap and names where it is enforced. The version that fails review is *it is usually small*. **The consumer's own handover is the brake.** If the terminal stage does its work inline and the producer emits on the delivering worker, the serialised handover already paces everything: the producer cannot start the next delivery until the consumer's processing returns. Unbounded demand then genuinely changes nothing. This argument has a sharp edge, though, and it is where people get it wrong — if the producer emits from **its own** worker, the handovers no longer run in the consumer's call chain, and the producer will simply queue ahead of a consumer that looks like it is pacing things. The argument is only valid when you can say which side drives the emission. **The stage is the last one and its sink is genuinely unbounded.** Writing to something that absorbs at an unbounded rate — and there are few such things — leaves nothing for demand to protect. ## Where it is a bug wearing a shortcut's clothes | Justification offered | Verdict | |---|---| | the source is capped by a validated request parameter | holds, if the cap is named | | the terminal stage processes inline on the delivering worker | holds, if the producer emits there too | | bounded requests made the code longer | does not hold | | it has run for months without failing | does not hold; it means the source has been slow | | something downstream will absorb the excess | does not hold; it relocates the problem | | the data crosses a process boundary and we want throughput | does not hold; that is where the bound matters most | The fifth row is the most common. Waiving flow control does not remove the mismatch between a fast producer and a slow consumer; it moves the consequence from a stalled producer, which is visible and cheap, into whatever sits between them. ## The shape of the rule A workable standard has four parts. 1. **Default deny.** No stage requests an unbounded count unless the exception is argued in the change that introduces it. 2. **Name the other bound.** The exception must say what limits the flow instead — the validated cap, the inline consumer with the producer emitting in its call chain, the finite materialised collection. An exception that cannot name one is not an exception. 3. **Bound anything crossing a boundary.** Where data crosses a process or a network hop, bounded requests are mandatory regardless of the above, because that is precisely where the two sides' speeds are least related and least observable. 4. **Make it visible.** The waiver should be greppable and reviewable rather than an incidental default, so an audit can find every place the system has opted out. ## What the rule costs, and how to keep that honest A rule that pushes everyone toward bounded requests has a real price, and pretending otherwise gets it quietly ignored. Requesting one value at a time means one request signal per value, which on a remote source is a round trip per value and can dominate the export's runtime. So the standard should set a **minimum sensible batch** and a replenishment policy, not a ceremony of single-value requests. The right default is a batch sized to what a stage can comfortably hold, replenished before it drains — bounded, but not chatty. There is also an organisational cost: engineers who have not hit a producer outrunning a consumer will read the rule as bureaucracy. The counter is evidence rather than principle — one incident, one graph of a stage that lost its brake — and a default in shared scaffolding so the bounded path is the path of least effort. A standard that is easier to follow than to evade is the only kind that survives.
- Why is an inline consumer only sometimes a valid justification?Because it depends on which side drives emission. If the producer emits within the consumer's call chain, the serialised handover blocks it until processing returns, so it genuinely cannot outrun anything. If the producer emits from its own worker, the handovers leave its call chain and it will queue ahead regardless of how slow the consumer is.
- A team argues unbounded demand is safe because their source is slow. Is that an argument?No, it is an observation about today's traffic. It says the mismatch has not appeared yet, not that it cannot. Sources get faster — a cache is added, a page size is raised — and the waiver stays in the code, so the protection disappears at the moment it first becomes necessary.
- What is the cost of writing the rule too strictly?Signalling overhead and a standard people route around. Demanding single-value requests turns every remote page into a round trip per value, which can dominate an export's runtime. Specify a minimum batch size with a replenishment threshold so the bounded path is also the fast path.
saying these in an interview costs you the question
- Treats an unbounded request as a performance tuning knob
- Says it is fine because a buffer downstream will absorb the excess
- Argues from the absence of past incidents rather than from a bound
- Waives flow control precisely where data crosses a process boundary
- Claims an inline consumer paces the producer without asking who emits
- Responds to signal chatter by removing the bound instead of batching