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

7 / 27

Refuse new work while the application can still recover

Application-owned admission

EnoughToo littleLocal headroom?Accept expensive workRefuse beforeallocationPreserve cleanup +response capacity
  1. New request Not accepted yet

    Decision happens before expensive work

  2. Application check Can I retain more?

    Uses local resource pressure

  3. Existing work Must still finish

    Needs resources already promised

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

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

Admission decides whether new work may start.

Application-owned local admission protects room to finish work and respond.

0:00
Read transcript & diagram walkthrough

What you will learn

Application-owned local admission protects room to finish work and respond.

The application can make a decision before accepting more expensive work. That decision is admission. Load shedding means deliberately refusing some work so the work we keep has a better chance of finishing.

For local memory protection, observe the memory budget of this application process or container. Keep headroom: unused capacity for work already accepted, resource cleanup, and sending responses. When pressure is too high, refuse new work before making large allocations. Middleware is application code that runs around request handling; it is one place to perform this check.

HTTP is the request-and-response protocol used by the web. Its response status code tells the caller what happened. A 503 response can communicate temporary service overload. Producing that response still costs resources, so even refusal needs headroom.

Who owns this protection? Your application does. RateLimitly does not currently supply this memory-monitoring middleware. Local memory checks also do not protect every CPU, connection, or database limit. They address the resources this application can observe and control.

Diagram walkthrough
  1. Admission decides whether new work may start.

    Admission is a decision before new work starts. Load shedding deliberately refuses some work so admitted work has a better chance of completing.

  2. Keep headroom for accepted work, cleanup, and responses.

    Observe the resource limit that applies to this process or container. Leave space for accepted work, cleanup, and the response used to refuse more work.

  3. Under pressure, refuse early with an appropriate response.

    A temporary-overload response can use HTTP 503. Sending that response still consumes resources, so refusal must remain a cheap path.

  4. Local resource protection belongs to the application.

    This memory guard belongs to your application, not a current RateLimitly middleware feature. It does not directly protect every shared dependency.

Content revision: 07c7dd00db17

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

Does refusing a request cost nothing?

Show the explained answer

No. Refusal still uses resources, so the application needs headroom before it reaches a hard limit.

Integration guidance

Check local pressure before large allocations; bound retained/concurrent work and define the overload response.

Where the promise stops

This is application-owned protection, not a current RateLimitly local-memory feature or a complete resource policy.

Technical depth & sources

Concepts used here

Implementation detail

Choose runtime-aware signals and test threshold behavior under measurement delay, allocation spikes and cleanup costs. Platform concurrency limits can complement memory admission.

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 →