Pattern · seen in 5 breakdowns across 5 companies

Feedback-Controlled Load Management

Definition

Static limits are perpetually wrong. A fixed concurrency cap, queue timeout, or shed threshold encodes one moment's understanding of capacity into a number that traffic immediately outgrows or undershoots — too tight and the system rejects work it could handle; too loose and it melts before the limit triggers. Worse, static thresholds produce cliff behavior: the system is fully open until the instant it slams fully closed, and the synchronized rejections that follow seed retry storms that re-create the overload.

Feedback-controlled load management replaces the static number with a closed control loop. The system continuously measures a signal that reflects real load — queue wait, inflow versus outflow, high-percentile latency, error rate — compares it against a target, and smoothly adjusts admission: how many requests to accept, how long to queue them, what fraction to shed. The controller incorporates not just the current error but its history and trend, which is what produces stability — gradual corrections instead of overreactions, a dimmer switch instead of a hammer. Because the loop measures outcomes rather than assumptions, it adapts to capacity changes (hardware, workload mix, downstream slowness) without anyone retuning a config.

The pattern's lineage runs through decades of systems: TCP congestion control is a feedback loop over packet loss and round-trip time (TCP Vegas, which some modern shedders directly adapt for concurrency auto-tuning); CoDel regulates queues by measured sojourn time rather than length; Netflix's adaptive concurrency limits compute limits from observed latency gradients; and Uber's Cinnamon applies a PID controller to request shedding, with a pluggable-signal design that feeds heterogeneous overload indicators — local concurrency, memory pressure, replication lag — into one unified decision loop, eliminating the split-brain behavior of independent per-signal limiters.

The deeper principle has two halves. First: measure the system you have, not the system you provisioned. Second: when several controllers act on the same resource, unify them — competing feedback loops fight, oscillate, and make globally incoherent decisions; one loop consuming many signals makes one coherent decision.

When it applies

01Admission control and load shedding for services whose capacity varies with workload mix, hardware, or downstream health — anywhere a static threshold needs perpetual retuning.

02Replacing cliff-shaped overload behavior (fully open → fully closed) with smooth degradation, especially where synchronized rejections trigger retry storms.

03Auto-tuning concurrency limits, queue timeouts, or rate caps from observed latency and error signals rather than provisioned estimates.

04Unifying multiple overload signals (local resource pressure, replication lag, tenant skew) into a single admission decision, where independent per-signal limiters would conflict.

Tradeoffs

The tuning burden moves rather than vanishes. Per-service static configuration disappears, but the controller itself must be made stable — gains, targets, and damping that neither oscillate nor respond sluggishly — and that calibration is paid at the platform level, often through several iterations before the loop behaves across diverse workloads.

Feedback loops are harder to reason about than thresholds. 'Why was this request shed?' has a one-line answer under a static limit and a controller-state answer under feedback control; operators need visibility into the loop's inputs and decisions or they will distrust it during incidents.

Signals must be normalized to compose. A loop consuming heterogeneous inputs (latency, lag, bytes, counts) needs them on scales that combine meaningfully; a badly scaled signal can dominate or destabilize the decision.

Control latency is real. A loop that measures outcomes necessarily reacts after the fact; sudden load steps are absorbed by the loop's response time, which is why feedback control complements — rather than replaces — client-side discipline like backoff and jitter.

The same move, 5 ways

Every row is a production system that bet on this pattern — the note says how, in that system's own terms.

Uber

Uber Engineering

2026

Instead of a fixed threshold that snaps fully open or fully shut, a controller adjusts how much to admit smoothly and continuously, using live latency and error signals as feedback (the same idea as a thermostat holding a temperature). Cinnamon's PID controller is the worked example, and its BYOS design extends the same loop to any overload signal (commit lag, write bytes, memory pressure), so what used to be several competing limiters becomes one coherent decision. Read the breakdown →

Netflix

Netflix Technology Blog

2024

Netflix's adaptive concurrency limits are a feedback loop straight out of TCP congestion control: the limit is recalculated each sample from how much responses have slowed (newLimit = currentLimit x gradient + queueSize, where the gradient is best-case latency divided by current latency), with no manual tuning and no central coordinator. When things are fast the limit grows; when they slow it shrinks. The prioritized shedding sits on top and decides which requests to drop once that self-discovered limit is hit. Uber's Cinnamon runs a similar loop with a PID controller over queue and latency signals; both are the same idea of measuring the system you actually have instead of hard-coding a fixed threshold. Read the breakdown →

DoorDash

DoorDash Engineering Blog

2023

Third company. The adaptive concurrency limit is a feedback loop in miniature (latency rises → limit tightens), and Aperture promotes the same loop to a platform: arbitrary normalized signals — Prometheus metrics, SLO deviation — feed one controller producing coordinated actuation, the architecture Uber's Cinnamon called BYOS. DoorDash names the anti-pattern this unification prevents: independent local mechanisms whose uncoordinated actions interact badly during exactly the failures they exist to stop. The post's argument is precisely that the local scale of this loop is insufficient. Read the breakdown →

LinkedIn Engineering

2023

Here the pattern takes a test-and-back-off form: a starting cap based on the load just before the overload, a survivable level held on detector feedback, occasional upward tests, and a doubling wait when a test brings the overload back. The cap is worked out fresh at each overload, because neither the traffic mix nor the kind of overload repeats. No control-theory machinery, just the same closed loop. Read the breakdown →

Stripe

Stripe Engineering

2017

The worker shedder is a feedback loop: it watches how busy the workers are and sheds more when they're overloaded, less when they recover. Its lesson is a tuning scar Stripe published: if it sheds and restores too fast, it oscillates, dropping traffic, seeing health return, restoring it, and immediately overloading again ('I brought it back! Everything is awful!'). The fix is to move slowly in both directions, which trades some reaction speed for stability. Uber and DoorDash build the same kind of loop with more formal control math (PID, AIMD); Stripe found the right damping by trial and error and, usefully, wrote up the failure it hit on the way. Read the breakdown →

Often used together

Patterns sharing breakdowns with this one — derived from co-occurrence, threshold ≥2 shared.

priority-aware-load-shedding ×5

Problems this pattern answers

The walls where its breakdowns live — each opens the cross-company comparison.

Priority-blind load sheddingLINKEDIN · NETFLIX · STRIPE · UBER →Mitigation scoped narrower than the failureDOORDASH →