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

17 / 27

Measure the operation whose pressure you want to observe

Timing and reporting

STARTSTOPOne operationLatency = finish time − starttimeSTARTOne operationSTOPLatency = elapsed timeFinish time − start time
  1. Start Begin the stopwatch

    Immediately before the chosen operation.

  2. Stop Finish the stopwatch

    At its defined endpoint.

  3. Latency Elapsed time

    Finish time minus start time.

Brackets mark the stopwatch interval. Labels and line patterns distinguish boundaries. Order only—not a time scale.

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

Choose the operation before choosing a threshold.

Define one meaningful stopwatch boundary before interpreting its measurements.

0:00
Read transcript & diagram walkthrough

What you will learn

Define one meaningful stopwatch boundary before interpreting its measurements.

Latency is how long an operation takes. To learn about a shared database, measure the database operation, not the whole page including unrelated work. A measurement boundary says exactly when that stopwatch starts and stops.

For example, start just before asking for a database connection, and stop when the required database result arrives. This boundary includes waiting for a connection and the query itself. Another boundary could start after the connection is acquired. Neither number is meaningful unless you know which boundary produced it and use it consistently.

A report is an observation sent to RateLimitly: this operation took this much time. Report after the measured work reaches its defined endpoint. Reporting an observation is not consuming a rate-limit allowance. Do not send a made-up zero duration when a call fails or a measurement is missing.

If the measured time rises, work inside that boundary is taking longer. That may include waiting, actual computation, or communication. The number is useful evidence, but it does not directly reveal the database's memory usage or the exact cause of the delay.

Diagram walkthrough
  1. Latency is the elapsed time between a start and a finish.

    Follow one operation from START to STOP. Its latency is the time between those two events, not the number of operations performed.

  2. Measure the database work, not the entire page.

    The page also does unrelated work. The solid bracket isolates the database operation; dashed boxes remain outside that interval.

  3. A boundary is a precise choice of start and stop.

    Decide which events begin and end the stopwatch. Without that definition, a duration cannot tell another developer which work it describes.

  4. Start A before asking for a database connection.

    Connection acquisition is inside this chosen boundary. Time spent waiting for an available connection therefore contributes to A, before the query can run.

  5. Stop A when the required database result arrives.

    Submitting a query is not the endpoint. Keep measuring through the query and the return of the required result; later page work is excluded.

  6. A includes connection acquisition plus the query and result.

    Read the full solid bracket. Both acquisition and database work contribute to this observation; unrelated page work does not.

  7. B starts later, after the connection has been acquired.

    This is the same operation, not a second request. A and B stop at the same result, but B deliberately leaves connection acquisition outside its stopwatch.

  8. Compare matching boundaries, not just duration values.

    A longer A does not by itself mean its query was slower than B: it includes additional work. Use a consistent definition across clients, or deliberately separate different observation scopes.

  9. The application sends the measured duration to RateLimitly.

    The stopwatch belongs around the chosen operation. Reporting communicates its observed duration; RateLimitly does not execute the database query shown here.

  10. Stop the timer first. Then report the observation.

    The reporting arrow lies outside the stopwatch bracket. Sending the observation must not extend the duration of the database operation being reported.

  11. Reporting duration is not consuming a rate-limit allowance.

    This message says how long the measured operation took. It is an observation, not a request to consume tenant allowance and not an admission decision.

  12. Missing timing is not zero milliseconds.

    A failed call or missing measurement does not prove that no time elapsed. Do not fabricate a zero-duration observation; define how valid timing, failures, and cancellations are handled.

  13. Longer time means more time inside the same boundary.

    Keep the definition fixed when interpreting a change. The observation is that the measured operation took longer; it does not yet identify why.

  14. Waiting, computation, and communication can all contribute.

    These are possible contributors, not three measured components or a diagnosis. Which are included depends on the chosen stopwatch boundary.

  15. A duration is evidence, not a memory reading or a diagnosis.

    The stopwatch tells us elapsed time within its boundary. It does not directly measure database memory, reveal an exact queue length, or establish the cause of the delay.

Content revision: 07c7dd00db17

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

One client includes connection waiting and another excludes it. Are their durations directly comparable?

Show the explained answer

Not necessarily. They measured different operations. Use consistent boundaries or separate appropriately scoped trackers.

Integration guidance

Start before the protected operation, report its actual measured duration after the defined endpoint, and define how failures and cancellations are observed.

Where the promise stops

Do not manufacture a zero-latency report for missing or failed measurements. Reporting semantics must match the measured operation.

Technical depth & sources

Concepts used here

Implementation detail

Including pool acquisition can expose upstream contention, while excluding it isolates another boundary. Heterogeneous operation costs may need separate trackers.

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 →