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 13 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 You are here
  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
  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.

13 / 27

A rate limit checks one customer’s recent allowance

Two tenants, separate policy decisions

OOrchidOwn recent useCheck firstSeparate usage recordNNorthstarOwn recent useCheck firstSeparate usage recordAsk whose allowance is being used.OOrchidOwn recent useCheck firstSeparate usage recordNNorthstarOwn recent useCheck firstSeparate usage recordAsk whose allowance isbeing used.
  1. Orchid Own usage record

    Not Northstar’s usage.

  2. Northstar Own usage record

    Maya belongs to this customer.

O square = Orchid. N circle = Northstar. Arrows follow each tenant’s decision, not dedicated hardware. Northstar is assumed within its own policy; other checks still apply.

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

Account for recent use within one tenant’s scope.

A rate limit enforces an allowance, not a measurement of current resource health.

0:00
Read transcript & diagram walkthrough

What you will learn

A rate limit enforces an allowance, not a measurement of current resource health.

A rate limit answers a specific question: has this tenant used its allowance recently? The allowance is how much work the policy permits. A time window is the period over which that use is considered.

For a simple example, suppose Orchid may start sixty ordinary reports per minute. The next report may be refused when its allowance is exhausted. The response can use HTTP status four twenty-nine, meaning too many requests for this policy. No expensive report should start after that refusal.

The exact algorithm matters. Some policies permit a short burst, meaning several requests close together. RateLimitly uses an estimate that decays over time; do not mistake this example for an exact calendar-minute counter. A work weight charges a more expensive operation more than a cheap one, when the application can assign meaningful relative costs.

Does sixty requests per minute guarantee low memory usage? No. Those requests can take different amounts of time and memory. The allowance controls recent use, while the application's local protection still controls its own resource risk.

Diagram walkthrough
  1. Start with the tenant, not the whole service.

    Each tenant has its own intended usage record. Orchid’s use does not consume Northstar’s allowance; both still use shared infrastructure.

  2. The window says which recent use matters.

    Allowance and time scale form a policy. This is a question about recent use, not a measurement of memory or database health.

  3. Orchid’s example policy: 60 ordinary reports per minute.

    The number describes the intended policy. It is not a display of an exact fixed-window counter. Northstar keeps its own allowance.

  4. Refuse Orchid’s excess; do not stop every tenant.

    Here Orchid has exhausted its allowance while Northstar remains within its own. Maya’s work may pass this fairness check; it must still pass other required checks.

  5. 429 identifies the policy refusal.

    This is the application responding to Orchid’s excess request. It is not a database error and does not say that the entire service is down.

  6. Make refusal a real branch: no expensive report starts.

    The refused branch must skip the costly operation. Returning 429 but continuing the same report in the background defeats this protection.

  7. The usage estimate decays; it does not reset on a clock boundary.

    Time passing reduces estimated recent use. Do not infer a fresh full allowance at the next calendar minute from this example.

  8. Charge costly work more when you can assign meaningful weights.

    A policy charge can represent relative cost. It still is not a direct reading of current memory or database capacity.

  9. A start-rate allowance is not a memory budget.

    Longer operations can retain more simultaneous work even at a bounded start rate. Keep application-owned memory and concurrency bounds alongside tenant fairness.

Content revision: 07c7dd00db17

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

Sixty requests pass the policy. Are their memory costs necessarily equal?

Show the explained answer

No. Request costs and durations vary; weights help express a policy but do not replace resource protection.

Integration guidance

Choose a tenant scope, allowance, time scale, and any meaningful work weights. Check before costly work and handle a policy denial explicitly.

Where the promise stops

The sixty-per-minute example illustrates a policy, not an exact fixed-window guarantee of RateLimitly’s decaying estimator.

Technical depth & sources

Concepts used here

Implementation detail

A rate bound is not a concurrency bound. Long-lived accepted work can accumulate even when its start rate is limited.

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 →