Debounce, Throttle, Rate Limit and Friends: 18 Flow-Control Patterns in Simple English

Every new event restarts a timer. The action runs only after events stop for a set time. If events may never stop (like auto-save while typing), also set a maximum wait, or it will never run.

Use it for: Search-as-you-type, auto-save, window resize.

The action runs at most once per time window. Events that arrive in between are skipped. Most tools also run once more at the end of a burst, so the last value (like the final scroll position) is not lost.

Use it for: Scroll and mouse-move handlers, progress updates, game input.

Small items go into a buffer. When it is full, or a timer fires, all items go out in one call.

Use it for: Sending logs and metrics, bulk database inserts, analytics events.

Handle a small share of events and skip the rest. The share can be fixed (1 in N) or random.

Use it for: Tracing, debug logs, analytics on very busy systems.

When several callers ask for the same thing at the same time, make one real call and give every caller the same answer. This avoids a "thundering herd". It is not caching: it shares a call that is still running, while a cache stores finished answers.

Use it for: Cache misses, popular API calls, loading the same file many times.

Give each request a unique key. Remember keys you have handled, and skip any key you have already seen. Keep keys for a limited time, or the list grows forever.

Use it for: Double-clicked "Pay" buttons, retried webhooks, message queues that deliver twice.

Cap how many requests a user, key or IP can make in a time window. Extra requests usually get 429 Too Many Requests, often with a Retry-After header. The diagram shows a token bucket: it refills at a steady rate, and a full bucket lets a short burst through.

Use it for: Public APIs, login attempts, protecting paid third-party services.

Like a rate limit, but over a long period, such as a day or a month. Often tied to a plan or a price. When it runs out, APIs usually return 429 or 403.

Use it for: Free vs. paid API plans, storage limits, monthly AI token budgets.

Limit how many jobs run at once. New jobs wait for a free slot. Usually built with a semaphore. A bulkhead goes one step further: each dependency gets its own limit, so one slow service cannot use up every slot.

Use it for: Database connection pools, calls to a slow service, CPU-heavy work.

Keep data in memory between a producer (sends data) and a consumer (reads data) that work at different speeds. A buffer smooths out the speed difference. Keep it a fixed size, or it can fill up memory.

Use it for: Video streaming, file reading and writing, network sockets.

Put jobs in a first-in, first-out (FIFO) list. Workers take jobs from the front at their own speed. A buffer smooths speed; a queue keeps order and hands work to workers, often for later.

Use it for: Sending emails, image processing, background jobs.

When the receiver's queue is full, it signals the sender to pause or slow down, so memory does not fill up. Some systems drop or block instead of pausing.

Use it for: Streams, message brokers, data pipelines.

When the system is overloaded, reject low-priority requests before they use up resources, so the important ones still work. This usually returns 503, often with Retry-After, and clients should wait before trying again.

Use it for: Keeping checkout alive during a sale, protecting core APIs during spikes.

Set a deadline for every call. If there is no answer in time, give up and return an error. The other side may still finish the work, so be careful when you retry.

Use it for: Every network call, database query and external API.

Many errors are short. Retry them, but double the wait after each failure so you do not overload a service that is struggling. Always set a maximum number of tries and a maximum wait. Only retry actions that are safe to repeat (idempotent): reads, or writes with an idempotency key (see Deduplication).

Use it for: Network blips, rate-limited APIs, brief outages.

If many clients retry on the same schedule, they all hit the server at the same moment. Use a random wait instead of an exact one, for example anywhere between 0 and the backoff time. This spreads them out.

Use it for: Any retry or timer used by many clients at once.

After too many failures in a row, the breaker opens and calls fail fast without waiting. After a pause it goes half-open: one test call checks if the service is back.

Use it for: Calls to other services and third-party APIs.

When the main source fails, answer from a backup: a cache, a default value, or a simpler feature.

Use it for: Showing cached prices, default recommendations, a read-only mode.