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 21 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
  4. 20 Separate local histories can reopen into the same burst
  5. 21 Replace optional expensive work before refusing essential work You are here
  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.

21 / 27

Replace optional expensive work before refusing essential work

Priority-based degradation

Refuse expensive workAllowShared signal: 600 msOptional threshold:500Essential threshold:900Precomputed releaseslistEssential read
  1. Optional suggestions Personalized list

    Nice to have

  2. Essential reads Core customer task

    More important to preserve

  3. Cheap fallback Precomputed releases

    Acceptable alternative

Illustrative mechanism. Highlight follows the explanation; not a benchmark.

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

Not every operation has the same customer importance.

Drop optional cost first, using a genuinely cheap and acceptable fallback.

0:00
Read transcript & diagram walkthrough

What you will learn

Drop optional cost first, using a genuinely cheap and acceptable fallback.

Some work matters more than other work. Criticality is that difference in importance to the customer's task. A fallback is an acceptable alternative result. Graceful degradation means doing less expensive work while still delivering a useful, correct experience.

During the live show, personalized video suggestions are optional. A precomputed list of recent releases is a cheaper fallback. It must not call the same overloaded database to create that list on demand, or it has not removed the expensive work.

Suppose optional suggestions use a five-hundred-millisecond threshold, while essential reads use nine hundred. These are illustrative policy choices, not recommended settings. At a shared signal of six hundred, the optional guard refuses the expensive suggestions, but the essential guard can still admit its work. The application returns the cheap list instead.

At one thousand milliseconds, both positive thresholds are exceeded, so essential work can be refused too. Degradation is not a promise that everything succeeds. Protect more important work for longer, and never silently substitute an incorrect answer for a correctness-sensitive operation.

Diagram walkthrough
  1. Not every operation has the same customer importance.

    Criticality describes importance to the customer’s task. Graceful degradation removes optional work while preserving a correct useful result.

  2. The alternative must avoid the expensive operation.

    A fallback must avoid the expensive dependency. Building the supposedly cheap list from the same overloaded database defeats the purpose.

  3. At 600 ms, shed optional work before essential work.

    Illustrative policy: at 600 ms, the 500-ms optional guard refuses while the 900-ms essential guard still admits. Your application chooses the fallback.

  4. At 1,000 ms, essential work can also be refused.

    At 1000 ms both positive thresholds are exceeded. Essential work may also be refused; never substitute an incorrect result for a correctness-sensitive operation.

Content revision: 07c7dd00db17

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

A fallback makes another expensive call to the same overloaded database. Did it remove that pressure?

Show the explained answer

No. It moved the same burden into a different branch. A useful fallback must actually avoid the protected expensive work.

Integration guidance

Define business criticality, safe precomputed or cached alternatives, and per-operation thresholds. Return the alternative only where it preserves the intended contract.

Where the promise stops

500 ms and 900 ms are illustrative, not sizing guidance. Different thresholds do not guarantee essential work always succeeds.

Technical depth & sources

Concepts used here

Implementation detail

Track degraded-but-useful responses separately from failures. Avoid fallback stampedes and preserve correctness-sensitive write semantics.

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 →