Skip to main content
Ratelimitly logo
Ratelimitly

Keep your API fast—even at peak

Rate limiting and admission checks that help reduce overload and protect expensive work.

Request early access Customer Log in

Reliable at peak

Set admission budgets for launch spikes and promos before excess work reaches your handlers.

Lower cloud costs

Fewer moving parts to run and monitor. Spend less on Redis and ops.

Dev‑first adoption

Add via SDK. Keep your stack. Clear limits your customers understand.

Request early access

UNDERSTAND OVERLOAD · KEEP USEFUL WORK MOVING

Keep useful work moving.

For developers, architects, and managers: 27 narrated lessons on why services overload and how to protect them. No cloud experience required. Start with one request, or jump to any lesson.

Course map Lesson 19 of 27 Browse all lessons

Four chapters, one learning path. Read or listen in any order. ~41 minutes total · Times shown at 1×.

Keep enough capacity to finish work and recover.

  1. 01 A useful result starts with one request
  2. 02 Unfinished work grows when arrivals outrun completions
  3. 03 More waiting space does not make work finish faster
  4. 04 A timeout ends waiting, not necessarily the work
  5. 05 Retained work can exhaust a process’s memory
  6. 06 One failed copy can push its neighbors over capacity
  7. 07 Refuse new work while the application can still recover
  8. 08 Different compute platforms still have finite resources
  9. 09 A shared database failure can spread back into every app
  10. 10 Restore capacity before restoring full traffic
  11. 11 A circuit breaker stops repeating a failing call

Contain one customer's excess without punishing everyone.

  1. 12 One customer’s excess should not ruin another’s day
  2. 13 A rate limit checks one customer’s recent allowance
  3. 14 Copies and languages must share the same intended policy
  4. 15 Fairness helps contain damage without reserving every resource
  5. 16 A legitimate crowd can exceed shared capacity

Reduce work entering a shared dependency when it slows.

  1. 17 Measure the operation whose pressure you want to observe
  2. 18 A shared tracker observes; a guard decides; your app acts
  3. 19 Even the fastest recent observations can become slow You are here
  4. 20 Separate local histories can reopen into the same burst
  5. 21 Replace optional expensive work before refusing essential work
  6. 22 A local breaker learns after calls have already piled up
  7. 23 Fast errors explain why the protections remain complementary
  8. 24 Latency feedback helps without measuring exact spare capacity

Choose, combine, and test the right protections.

  1. 25 Ask three different questions before expensive work
  2. 26 Recovery attempts need limits too
  3. 27 Measure useful service, not how much work you accepted

Read the explanation or use the course map above. Audio is optional.

19 / 27

Even the fastest recent observations can become slow

Eligible minimum comparison

Eligible observationsFastest observationthat still counts
  1. History rules Choose eligible observations

    Only observations that still count enter the comparison.

  2. Minimum Choose the fastest

    Not the average or a percentile.

Illustrative measurements. Each example appears when the narration introduces it.

Read the numbered steps in order. The explanation below follows the narration.

Minimum means the fastest measurement that still counts.

The eligible recent minimum is a pressure signal with freshness and missing-data limits.

0:00
Read transcript & diagram walkthrough

What you will learn

The eligible recent minimum is a pressure signal with freshness and missing-data limits.

Which latency number does the guard use? RateLimitly uses the minimum among recent eligible observations: the fastest measurement that still counts under the tracker's configured history rules. It is not an average or a percentile. Freshness means how recent an observation is.

Imagine the eligible measurements are eighty, ninety, and one hundred milliseconds. The minimum is eighty. Now imagine the eligible set contains six hundred, six hundred twenty, and seven hundred. Its minimum is six hundred. Even the fastest eligible operation is now slower than a five-hundred-millisecond threshold, so that guard refuses new work.

But if an old eighty-millisecond sample still counts, the minimum stays low. That old fast result can mask newer slow results until it stops being eligible. Sparse history means too few eligible observations. The current implementation treats insufficient history optimistically; a zero signal there is not proof of a healthy database.

Sharing reports improves what clients can observe together. Freshness, history settings, and independent resource bounds still matter. Do not interpret an old fast result or missing evidence as guaranteed spare capacity.

Diagram walkthrough
  1. Minimum means the fastest observation that still counts.

    Eligibility determines which observations still count under the configured history rules. The minimum is the fastest of those—not an average, percentile, or exact queue length. Freshness describes how recent an observation is.

  2. First example: 80, 90 and 100 milliseconds.

    These three eligible measurements are 80, 90 and 100 ms. Find the smallest duration among the measurements that count under the configured history rules.

  3. The fastest of these observations is 80 ms.

    Of 80, 90 and 100 ms, the smallest duration is 80 ms. That is this eligible set’s minimum; it does not describe every request or prove spare database capacity.

  4. Second example: 600, 620 and 700 milliseconds.

    Now the eligible set contains 600, 620 and 700 ms. This is a different example: the earlier 80-ms observation is not part of this set.

  5. Even the fastest observation is now 600 ms.

    The minimum of 600, 620 and 700 ms is 600 ms. All eligible observations in this example are at least that slow.

  6. Compare the 600-ms signal with the 500-ms threshold.

    The fastest eligible observation is 600 ms, above this guard’s illustrative 500-ms threshold. The comparison includes equality; the threshold is not a timer that cancels work.

  7. The guard refuses new work.

    Because 600 ms is at or above the positive 500-ms threshold, the guard refuses this new operation. Your application must obey the decision and skip the protected work.

  8. An old fast sample can keep the minimum low.

    If an old 80-ms observation still qualifies alongside newer 600, 620 and 700-ms observations, the minimum remains 80 ms. That can mask current pressure until the old observation stops being eligible.

  9. Sparse history: too few eligible observations.

    This is a different limitation from an old fast observation: too few measurements qualify to satisfy the tracker’s required history. Missing evidence is not a measured fast response.

  10. A zero signal is not proof of a healthy database.

    The current implementation treats insufficient history optimistically. Its zero signal in that case is not proof of a healthy database or measured spare capacity; independent resource bounds still matter.

  11. Shared evidence still has limits.

    Sharing real observations improves the common view. Freshness and history settings still determine the signal; keep independent resource bounds rather than treating old or missing evidence as guaranteed capacity.

Content revision: 07c7dd00db17

Download review copy (27 lessons)
Check your understanding & apply it

A zero signal came from insufficient history. Does zero prove the database is fast?

Show the explained answer

No. It represents optimistic handling of missing evidence, not a measured guarantee of health.

Integration guidance

Keep tracker history settings consistent, supply actual observations, and test old fast samples, sparse history, and sudden slowdowns.

Where the promise stops

This is the eligible recent minimum, not an average, percentile, memory meter, or exact queue-depth measurement.

Technical depth & sources

Concepts used here

Implementation detail

A lingering fast sample can delay refusal; optimistic sparse history can reopen admission. Bound resources independently and test the full feedback delay.

Original explanation inspired by Fred Hébert and operational references; no endorsement implied.

AI-generated narration: ElevenLabs Eleven v3, Daniel stock voice. Audio streams only when you start listening.

ElevenLabs

Why teams choose us

Happier customers
Consistent response times when it matters most.
Faster delivery
Ship features, not DIY limiters and brittle ops workarounds.
Clear controls
Per‑tenant and per‑route limits your stakeholders can reason about.

Engineering blog

View all posts →

Why you shouldn’t use Redis as a rate limiter: Part 1 of 2

A tour of the common Redis-based rate limiter implementations — and the correctness and performance traps each one hides.

Read more →

Auto-Scaling Won’t Save You

The myth of infinite serverless scale — why adding machines doesn’t fix overload, and what to do instead.

Read more →