Debouncing delays an action until a burst of triggering events has stopped for some quiet period. It's the cousin of throttling, but with a different contract: throttling caps the rate (fire at most once per N ms), while debouncing waits for silence (fire only after N ms of no new events). Confuse the two and you'll ship the wrong UX.

The canonical example: search-as-you-type. A user types "kubernetes" — that's 10 keystrokes in ~1.5 seconds. Without debouncing, you fire 10 API requests, most of which return stale results by the time they arrive, and your autocomplete flickers. With a 300ms debounce, you fire one request, 300ms after they stop typing. Same UX, 90% less load.

Rule of thumb for the debounce interval:

• 150–250ms — UI feedback (resize handlers, scroll-driven layout). Users notice latency above this.
• 300–500ms — Search-as-you-type, form validation. Long enough to skip inter-keystroke gaps, short enough to feel responsive.
• 1–5s — Autosave, "did the user stop editing?" signals. Wasted work is expensive; latency doesn't matter.

Leading vs trailing edge matters. Trailing debounce (the default) fires after the quiet period — good for search. Leading debounce fires immediately, then ignores events until quiet — good for "prevent double-click submission." Some libraries offer both edges: fire immediately AND again after quiet. Pick deliberately; the wrong edge feels broken.

The subtle bug: unbounded delay under sustained input. A trailing debounce with a 500ms delay will never fire if the user keeps typing every 400ms. For autosave, this means a user editing continuously for 10 minutes has saved nothing. Fix it with a maxWait: "fire at least every N seconds regardless of activity." Lodash's _.debounce(fn, 500, { maxWait: 3000 }) guarantees a fire every 3 seconds even during sustained input.

Cancellation is non-negotiable. If the user navigates away, or a component unmounts, the pending debounced call must be cancelled — otherwise you're calling setState on a dead component or firing a request whose response has nowhere to go. Every real debounce implementation exposes .cancel() and .flush(). Use them in your cleanup hooks.

Where debounce goes wrong: applying it to events that need every occurrence (analytics, audit logs), or debouncing on the server for events that should be idempotent-per-request. Debounce discards intermediate events by design — if intermediate events matter, use batching or a queue, not debounce.