Backpressure

Description

Flow + feedback loop: when downstream processing slows, the slowdown propagates upstream as a signal to throttle. Without backpressure, fast upstream + slow downstream produces buffer overflow, dropped work, or cascading failure; with backpressure, the system self-regulates to the bottleneck rate. One of the most reliably-applicable bundles across queues, supply chains, traffic merges, and social dynamics.

Composition

= flow + feedback-loop. The flow is the moving content (items, work, data, messages); the feedback loop is the upstream signal that downstream can’t keep up. Both must be present — flow alone produces overflow; feedback without flow produces no observable behavior.

When it applies / triggers on

Caveat — low corpus support. Only 1 corpus match (via <task-notification> flavor); the lexical heuristic catches almost nothing because the form’s structural shape shows up via different vocabulary (rate-limit, quota, retry-storm, fan-out, concurrency-cap) than the literal name. The trigger-pattern below is anticipated based on the bundle’s catalog shape and the one observed exemplar — treat as deliberately wide net, to be refined as more empirically-grounded encounters accumulate.

User-initiated: Three anticipated trigger patterns (only one corroborated by corpus):

• Producer-faster-than-consumer — user describes a system where producer-rate exceeds consumer-rate (“the LLM calls are queueing faster than they can complete”, “we’re getting 429s under load”) → backpressure as the missing mechanism.
• Cascading-failure report — user reports “things falling over” or downstream slowdown propagating upstream as crashes/timeouts rather than throttling → backpressure-absence as the diagnosis.
• Retry-without-throttle proposal — user proposes adding retry logic without throttling (“add exponential backoff”) → backpressure-as-missing-pair (the one corroborated exemplar: “retry backoff is mathematically doomed against a 60s sliding-window quota… continuous-refill Token Bucket beats literal sliding-window array”).

Agent-initiated: Engine notices a proposed flow-control / retry / rate-limit design that addresses one half of the flow + feedback-loop pair but not the other (retry without throttle, or throttle without backpropagation signal). The <task-notification> flavor (1/1 of observed matches) suggests this is often an elephant-evaluating-goldfish-output context — the elephant catches a goldfish proposing a partial fix.

Vocabulary cues: Because the bundle’s name is rarely invoked, retrieval must lean heavily on synonyms — “rate limit,” “quota,” “throttle,” “429,” “retry storm,” “cascading failure,” “fan-out,” “concurrency cap,” “queue depth,” “token bucket,” “sliding window,” “retry budget,” “buffer overflow,” “slow downstream,” “back off.”

Situation-shape signals: Any flow with a feedback path candidate. A queue that fills without a way to signal upstream to slow down; a fan-out where the slowest consumer determines aggregate rate; an API quota where retry without throttle creates a retry-storm. (Per T2 gap notes: lexical net plausibly under-counts true encounter rate by 30-50×.)

Encounters

• SendMessage timing — agent orchestration: backpressure on subagent dispatch when downstream goldfish can’t keep up.
• Merge-cascade ordering — git workflow: rapid PR merges create upstream backpressure on review queues.
• Pipeline backpressure — KCC weekly pipeline: source-routing slowness propagates upstream as work-rate signal.

Composes with

• hysteresis — backpressure systems often exhibit hysteresis: once throttled, return to full throughput depends on the path taken, not just current state.

When it doesn’t apply

• Asynchronous fire-and-forget systems — no feedback channel, no backpressure possible by construction. Different failure mode: overflow.
• Hard-real-time systems — when downstream slowdown isn’t acceptable as a signal (must meet deadline), backpressure becomes “we have a problem” rather than “we self-regulate.”

Sources

• Fluid-dynamics origin (literal backpressure in pipes).
• Networking lineage (TCP windowing, RxJava backpressure).
• Reactive Streams specification.

Canonical exemplars from corpus (T2 2026-05-17)

• Retry-backoff vs sliding-window quota (cwd: campconnect, session: idx=0, task-notification flavor): “There are two bugs, not one. Our existing retry backoff (2s+4s+8s=14s total) is mathematically doomed against a 60s sliding-window quota. Continuous-refill Token Bucket beats literal sliding-window array — tokens refill at 15,000/sec, capacity 900K — mathematically equivalent in steady state but eliminates array-scan overhead and a class of edge-case bugs.”

Trigger pattern (T2): Cannot meaningfully extract from 1 match; anticipated triggers are user describing producer-rate exceeding consumer-rate, reporting cascading failure, or proposing retry logic without throttling — true trigger pattern unrecoverable from lexical heuristic; retrieval must rely heavily on synonyms (rate limit, quota, throttl, 429, retry storm, cascading, concurrency).