how does the system prevent demand from overwhelming capacity?

flow control  = regulate how fast work enters or moves
backpressure  = propagate downstream saturation upstream

Little's law:  L = λW
(in-flight = arrival rate × time-in-system)
rate limits and concurrency limits are coupled through latency —
limit one, and latency variance moves the other.

protect the system  vs  serve as much useful work as possible
(and the operative word is useful — see bottleneck*)

arrival rate:     per-time admission        (token/leaky bucket, per-user caps)
outstanding work: in-flight, however denominated —
                  requests (semaphore, pool, max in-flight)
                  bytes    (TCP window, HTTP/2 WINDOW_UPDATE, prefetch)
                  — the same control, two currencies
waiting depth:    queue occupancy           (bounded queue — owned by queue.md axis 5)
memory / cost:    buffer.memory, payload budgets, $-quotas

a rate limit calibrated at 10ms latency admits 100× the in-flight load
when latency degrades to 1s. rate limits assume a latency; concurrency
limits self-adjust. under latency variance, limit outstanding work.

What resource is actually scarce — CPU, memory, connections, downstream capacity?
Is the limit denominated in the same currency as the scarcity?
What latency did the rate limit silently assume?
Distributed limit: is the counter consistent, and does the key match the tenant?

slow the producer:  block / withhold credit      (lossless, needs obedient upstream)
queue it:           absorb burst                 (bounded! — else latency hides overload)
reorder it:         priority lanes, preemption   (scheduler.md axis 2 — reference, don't restate)
degrade it:         stale cache, shed features,
                    cheaper path                 (convert expensive work to cheap work)
reject it:          429/503 + Retry-After        (make overload the caller's problem, politely)

At what load level does each rung engage?
Is queueing bounded, and by time as well as depth?
What can be degraded before anything is refused?
Is a drop visible to the caller, or silent data loss?
Shed by priority: is the priority honest? (scheduler.md: abuse, inversion)

explicit credit:   receiver grants; sender cannot exceed
                   (TCP window, Reactive Streams demand(n), prefetch count)
implicit blocking: bounded buffer; producer stalls on write
                   (bounded channels, Kafka producer on buffer.memory)
out-of-band rejection: 429/503 + Retry-After — ADVISORY; caller may obey
inferred:          no signal; sender deduces from latency/loss/errors
                   (TCP congestion control, adaptive concurrency,
                    circuit breaker inferring dependency health)

credit and blocking are enforceable.
rejection is advisory.
inference is disciplined guesswork.
"backpressure ignored by producer" is only possible on the advisory rung —
if ignoring the signal is unacceptable, choose an enforceable mechanism.

Who receives the signal? CAN they obey it? What happens if they don't?
Is there a hidden unbounded buffer that absorbs the signal? (see axis 4)
For inferred: what does the sender actually observe, and how stale is it?
Blocking: can the stall propagate into a deadlock? (cycles in the flow graph)

ingress:  protect yourself from callers
          (admission control, rate limits at the gate, request queues)
egress:   protect the dependency from YOU — regulate self-generated demand
          (circuit breaker, retry budget, per-dependency pools, outbound limits)

the signal chain is only as strong as its weakest hop.
one hidden unbounded buffer anywhere silently absorbs the signal
and converts overload into latency + memory instead of upstream slowdown.
this is the thesis of the block, not a footnote.

Where does demand enter; where is saturation first observed; how many hops between?
Walk every hop: is its buffer bounded? (one "no" breaks the chain)
Ingress and egress both covered, or only the front door?
Cyclic topology: what prevents credit-wait deadlock?
Bulkheads (boundary.md #9): which failure classes share a pool?

static:    fixed limit; simple, predictable, wrong twice a day
adaptive:  feedback-controlled (adaptive concurrency, congestion control,
           queue-depth autoscaling, latency-based throttling)

oscillation           overreaction to a lagging metric
feedback delay        acting on a world that has moved (view-vs-reality*, scheduler.md)
bad setpoint          stable convergence to the wrong target
controller fights     HPA vs adaptive concurrency vs manual limits —
                      two loops, one plant, no coordination

What is the measured signal, the setpoint, and the actuation delay?
Why is the loop stable — argued, not assumed? (hysteresis? damping?)
What other controller acts on the same resource?
Autoscaling ≠ overload protection: what survives the minutes before capacity arrives?

the quantity that matters is not admitted work — it is admitted work
that completes usefully. throughput can stay high while goodput goes to zero.

requests queue past the caller's timeout, then get served anyway —
  the caller gave up; you are doing archaeology
retries amplify demand exactly when capacity fell
synchronized probes/backoffs arrive as a thundering herd
the system stays saturated at zero goodput even after the trigger clears

deadline propagation      carry the caller's remaining budget on every hop,
                          so dead work is droppable anywhere in the chain —
                          the flagship recipe, and the block's deepest idea
admission timeout         bound queues by TIME, not just depth;
                          never dequeue work older than its deadline
retry budget + jitter     retries ≤ fraction of originals; desynchronize
LIFO under overload       newest work has the freshest deadline —
                          fairness sacrificed for goodput, deliberately
circuit breaking          stop paying for a dependency that can't deliver
degraded modes            convert expensive work to cheap work before refusing any

what resource is scarce,
where each limit is enforced and in what currency,
how callers learn to slow down (and whether the signal is enforceable),
what gets queued, degraded, or shed — and how dead work is detected,
and how fairness is preserved under stress.

measure capacity or load
admit / delay / reject work
grant credit or permit
consume credit while work is in flight
release credit on completion
adjust limits from feedback
communicate retry/backoff to the caller

HTTP:             429 / 503 + Retry-After              (advisory rejection)
TCP / HTTP2:      window advertisement / WINDOW_UPDATE  (explicit credit)
Reactive Streams: subscriber requests N                 (explicit credit)
broker:           prefetch count, fetch max bytes,
                  producer buffer limits                (credit + blocking)
worker pool:      semaphore acquire/release             (implicit blocking)
gRPC deadline:    remaining budget on every hop         (deadline propagation)

capacity  demand  arrival rate  service rate  utilization  saturation
goodput  congestion collapse  metastable failure
in-flight  queue depth  backlog  latency
token  credit  permit  window  demand(n)  prefetch
limit  quota  reservation  budget
backoff  jitter  hedging  Retry-After  429  503
deadline propagation  admission timeout  LIFO-under-overload
shed  degraded mode  bulkhead
setpoint  feedback delay  hysteresis  oscillation

rate limit        vs  concurrency limit   (axis 1: Little's law couples them via latency)
queueing          vs  capacity            (axis 2: a buffer stores overload, doesn't serve it)
retry             vs  recovery            (bottleneck*: retries are self-made load)
latency           vs  load                (axis 5: the signal lags the cause)
throughput        vs  health              (bottleneck*: goodput is the real metric)
global limit      vs  tenant fairness     (scheduler.md: one gate ≠ fair shares)
autoscaling       vs  overload protection (axis 5: capacity arrives in minutes; collapse in seconds)