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

1 / 27

A useful result starts with one request

Message sequence

DatabaseApplicationMaya / browser1 · Open report2 · Read records3 · Records4 · Build report5 · Report response
  1. Maya → Application Open the sales report

    The browser asks the application to do work.

  2. Application → Database Read the sales records

    The application needs data before it can build the report.

  3. Database → Application Return the records

    The data has returned to the application, not yet to Maya.

  4. Application Build the report

    The application turns records into the result Maya asked for.

  5. Application → Maya Deliver the report

    Only a usable response completes Maya’s task.

Time runs downward. Solid arrows ask; dashed arrows return.

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

Maya needs a usable report.

Accepting a request is not the same as delivering a useful result.

0:00
Read transcript & diagram walkthrough

What you will learn

Accepting a request is not the same as delivering a useful result.

Maya needs her sales report before a meeting. Keeping useful results available is the goal of this explanation. You do not need cloud or networking experience to follow it.

When Maya clicks Open report, her browser sends a request: a message asking a computer to do something. The application is the program that receives that message and decides what work is needed. Here, it asks a database, a system that stores and retrieves the sales records.

The database returns the records. The application turns them into a report and sends a response back to Maya. A response is the answer to the request. Maya has succeeded only when she receives a usable report, not when the application merely accepts her message.

What if the application accepts the request but the report never arrives? The computer started something, but Maya still cannot do her job.

Diagram walkthrough
  1. Follow one request, end to end.

    Overview of the normal path. Maya uses the browser; the application builds the report; the database supplies records. A started request is not yet a delivered result.

  2. Maya has asked. She is still waiting.

    The request carries an instruction to the application. Accepting it starts work; it does not mean the report exists or has reached the browser.

  3. The application needs records first.

    This is a second call inside the original request. The application is a caller of the database while it is still serving Maya.

  4. Records have reached the application.

    The records have reached the application, not yet Maya. This internal completion is only one step of her request.

  5. The application builds the result.

    The application still has work to do after the query finishes. Database completion and customer completion are different events.

  6. The response travels back to Maya.

    The answer must reach the browser and be usable. Counting accepted requests alone misses this last part of the customer’s experience.

  7. Success belongs at the customer boundary.

    The useful outcome is Maya receiving her report. A query finishing internally is not sufficient evidence of that outcome.

  8. No usable report. Maya cannot finish.

    Alternative outcome: acceptance happened, but the response never arrived. This does not establish where the path failed or whether database work completed.

Content revision: 07c7dd00db17

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

The app accepted Maya’s request. Has she succeeded?

Show the explained answer

Only if a usable report reaches her. Acceptance alone is not a completed customer outcome.

Integration guidance

Identify the real customer result before choosing counters or failure indicators.

Where the promise stops

This example reads a report; a failed response would not by itself establish whether a write committed.

Technical depth & sources

Concepts used here

Start here. No earlier lesson is required.

Implementation detail

Measure successful, useful responses separately from accepted requests and internal completions.

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 →