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

9 / 27

A shared database failure can spread back into every app

Failure cascade

queriesqueriesApplication AShared databaseApplication BFinite query capacity
  1. Application copies Concurrent queries

    Each copy can create demand on the same resource.

  2. Shared database Finite capacity

    The copies depend on the same ability to complete queries.

Arrows show causal paths. Branches distinguish possible outcomes.

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

Many applications depend on the same database.

Database unavailable → calls wait or fail → unbounded retained app work can cause further failure.

0:00
Read transcript & diagram walkthrough

What you will learn

Database unavailable → calls wait or fail → unbounded retained app work can cause further failure.

A dependency is another component an application needs to complete some work. A database used by many application copies is a shared resource: all of those copies depend on its finite capacity. A database query is an operation asking it to read or change data.

Many applications send queries at once. If the database cannot finish them fast enough, active queries, connections, and waiting work can consume resources. Under some configurations, memory exhaustion may stop database operations or make the database unavailable. This is a possible severe outcome, not what every database must do.

The applications now wait for answers or receive connection errors. If they keep admitting requests and retaining waiting work, their own memory can grow. Unprotected application processes can fail as a consequence of the database failure.

With local memory protection, the applications may stay alive by refusing excess work. But can they produce a report that requires the unavailable database? No. Keeping the application process alive is useful, but it does not restore the missing dependency. Unavailability alone also does not prove stored data was lost.

Diagram walkthrough
  1. Several applications depend on one database.

    Adding application copies gives this shared database more callers. It does not give the database more capacity.

  2. Work can accumulate at the shared tier.

    Active queries, connection state and waiting work can all consume resources. Where the backlog lives depends on pools, limits and the database configuration.

  3. The database may become unavailable.

    This severe branch is conditional, not inevitable. Allocation failures or terminated database processes may disrupt service; unavailability does not prove data loss.

  4. Failure propagates through dependency calls.

    A missing answer can leave callers waiting. A broken connection can instead report an error quickly. Those are different paths with different retained-work costs.

  5. Retained work is the link to application OOM.

    The cascade requires retained work to keep growing. Fast errors with bounded cleanup do not automatically exhaust application memory.

  6. One shared failure can become a fleet failure.

    If application processes exhaust their own memory, the outage has spread beyond the database. More restarting app copies alone will not repair that shared dependency.

  7. Local shedding contains the secondary failure.

    Your application can refuse excess work before its own memory is exhausted. This protects its ability to respond, not the availability of the database.

  8. An alive process is not a restored service.

    No: a report requiring the unavailable database still cannot be produced. Explicit refusal is different from success, and unavailability does not prove data loss.

Content revision: 07c7dd00db17

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

Local memory guards keep the apps alive. Are database-backed reports available?

Show the explained answer

Not while the required database remains unavailable. Process survival and customer functionality differ.

Integration guidance

Bound application waiting and database concurrency; treat fast connection errors differently from deadline expiry.

Where the promise stops

Some databases refuse work or fail only an operation. This scene deliberately illustrates a stated severe database-unavailable branch.

Technical depth & sources

Concepts used here

Implementation detail

Failure scope depends on database/runtime configuration, connection behavior and memory enforcement. App OOM requires retained work to keep growing; fast errors with bounded admission can avoid it.

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 →