Debouncing and Throttling

Debouncing and throttling reduce work caused by frequent signals, but they make different promises.

• debouncing waits for a quiet period and coalesces a burst, commonly keeping the last value;
• throttling permits work no more frequently than a configured rate or interval while signals continue.

Debouncing suits search-as-you-type or repeated configuration reload signals. Throttling suits progress rendering or telemetry whose intermediate values may be sampled. Neither is appropriate when every event represents a required financial, audit, inventory, or workflow transition.

Semantic choices

State the following before implementation:

• leading edge, trailing edge, or both;
• whether the first, latest, or aggregated value wins;
• maximum wait during a continuous burst;
• key scope: global, user, document, or another entity;
• clock source and behavior when time moves;
• cancellation, shutdown, and exception policy.

A trailing-only debounce can postpone work forever when signals never stop; adding a maximum wait prevents starvation. A per-key implementation needs bounded key retention or cleanup. In a cluster, process-local state gives a per-instance policy, not a global guarantee.

Concurrency

Scheduling a replacement task and cancelling the previous one must be atomic with respect to the key. Cancellation may race with execution, so the action should tolerate an obsolete task or validate a generation number immediately before applying its effect. Never hold a shared lock while performing slow I/O.

Do not use Thread.sleep in request threads to implement either pattern. Use an appropriate scheduler, event loop, stream operator, gateway, or durable job mechanism according to the delivery contract.

Verification

Use a controllable clock or virtual scheduler. Test a single signal, bursts on both sides of the interval, continuous signals, concurrent keys, cancellation races, handler failure, and shutdown. Measure suppressed, executed, delayed, and failed work without labeling metrics by unbounded keys.

Rate limiting protects capacity and fairness across callers; it is covered with other resilience controls.