Skip to main content

Keep your API fast—even at peak

Rate limiting and admission checks that help reduce overload and protect expensive work.

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.

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

20 / 27

Separate local histories can reopen into the same burst

Independent histories and feedback delay

Env AOWN PASTKnows only localworkEnv BOWN PASTKnows only localworkEnv COWN PASTKnows only localworkShared databaseHistories stay separatePrivate histories; one shared dependencyEnv AOWN PASTKnows only local workEnv BOWN PASTKnows only local workEnv COWN PASTKnows only local workShared databaseHistories stay separatePrivate histories; oneshared dependency
  1. A / B / C Separate execution environments

    A serverless function may reuse an environment.

  2. Local history Own past work

    Not automatically a shared observation record.

Possible failure pattern, not measured traffic or a stability prediction. A/B/C keep separate local histories. Later results return to their originating environment; shared scope is introduced separately.

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

Separate environments have separate memories.

Local histories can synchronize a burst–refuse–reopen cycle; shared observations reduce fragmentation.

0:00
Read transcript & diagram walkthrough

What you will learn

Local histories can synchronize a burst–refuse–reopen cycle; shared observations reduce fragmentation.

A serverless execution environment can sometimes retain local state between requests. Keeping latency history there seems convenient: no additional service to run. But each environment knows only its own past, and a new one may know nothing.

Suppose many environments still remember fast work. They admit a burst into the same database. Slow results arrive only after that work finishes. This is feedback delay: decisions happen before the consequences become visible.

Those environments can then refuse work together. Few fresh results arrive while they refuse. Their old observations expire, and optimistic empty histories can let many environments reopen together. Another burst reaches the database. Repeated opening and refusing is an oscillation: the system swings instead of settling. This is a possible failure pattern, not a claim that every local controller behaves this way.

A shared tracker lets these clients contribute to and read the same intended observation scope. It reduces fragmented histories without operating a separate history store in each service. Sharing does not remove feedback delay or guarantee stability. Freshness, bounded work, and careful recovery remain important.

Diagram walkthrough
  1. A reused execution environment may remember its own past work.

    Each labeled box is a separate execution environment. A reused environment can sometimes retain local history between requests, but those local records are not automatically shared with the other environments.

  2. A new environment may start with no latency evidence.

    C illustrates a new environment with an empty history while A and B have their own past observations. Missing measurements do not establish that the shared database is healthy or has spare capacity.

  3. Worked case: local histories still describe earlier fast work.

    For the following possible failure pattern, consider environments whose histories retain old fast observations. Their earlier experience is evidence about the past, not a direct measurement of the shared database’s current pressure.

  4. Several environments admit work using old observations.

    Follow the three work routes into the same database. A, B, and C still have old fast evidence when admitting this burst; slow results from the newly admitted work have not returned yet.

  5. The evidence arrives after the expensive work has already run.

    Each returned result can update its originating environment’s local history. That result is delayed feedback about work already admitted; whether it changes the guard’s signal depends on eligibility and history rules.

  6. The decision happened before its consequences were visible.

    The new evidence comes from an operation admitted earlier. A client cannot use that operation’s final duration before the measurement finishes. Sharing evidence later does not remove this causal delay.

  7. Possible next state: local guards refuse together.

    Here the eligible histories cause the local guards to refuse new protected work. No new work routes reach the database. This is a possible branch, not a claim that every slow observation necessarily trips every guard.

  8. Refusing work also reduces the supply of fresh measurements.

    While these clients skip protected work, they produce few new completions to measure. Existing work may still return results, but a refusal itself is not a new database latency observation.

  9. The histories lose evidence; expiry does not prove recovery.

    The old observations stop qualifying under the history rules. That leaves too little current evidence in this illustrative branch. A history aging out does not itself make the database faster or add processing capacity.

  10. Optimistic empty histories can reopen into another burst.

    Follow the work routes returning together: the histories are empty, not freshly measured fast. Optimistic reopening can admit another combined burst before useful current evidence has accumulated.

  11. The cluster can swing: admit, refuse, then admit together again.

    Each row is one environment and each column is a stage, not a measured time interval. The matching shapes show a possible synchronized pattern: a burst, common refusal, and another burst instead of settling.

  12. Share the intended observation scope instead of isolated histories.

    The arrows now represent reports and admission checks, not database query traffic. A, B, and C contribute to and consult the same intended shared observation scope; they no longer rely only on their separate private past.

  13. Sharing helps the evidence; it does not guarantee stability.

    Sharing reduces fragmented histories but does not guarantee stable control or remove delayed feedback. Freshness rules, bounded work, and careful recovery remain necessary; there is deliberately no promised flat healthy throughput line here.

Content revision: 07c7dd00db17

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

All environments stopped sending work. Why might they reopen into another burst?

Show the explained answer

While refusing, they may receive few fresh completions. Expired local histories can trigger optimistic reopening at similar times.

Integration guidance

Use a shared, consistently scoped tracker across execution environments; test stale samples, new environments, expiry, and coordinated reopening.

Where the promise stops

Shared history helps but does not guarantee stable feedback, eliminate delay, or automatically make independent server state global.

Technical depth & sources

Concepts used here

Implementation detail

The closed loop includes admission, work completion, reporting, retention, and recovery. Test the whole loop under rapid changes, not only steady overload.

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.

Auto-Scaling Won’t Save You

The myth of infinite serverless scale — why adding machines doesn’t fix overload, and what to do instead.