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

8 / 27

Different compute platforms still have finite resources

Where code runs, what is active, and what remains shared

RequestAsks for a reportComputeApplicationRuns instructionsCompute runs application codeRequestAsks for a reportComputeApplicationRuns instructionsCompute runs applicationcode
  1. Request Asks for work

    A report is requested.

  2. Compute Runs the application

    Real resources execute the instructions.

Illustrative placements and operation counts, not platform defaults. Readiness, concurrency scope and memory signals depend on the platform. Local memory admission belongs to your application.

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

Compute runs application instructions in several deployment forms.

Serverless and autoscaling change how compute is supplied, not whether resources are finite.

0:00
Read transcript & diagram walkthrough

What you will learn

Serverless and autoscaling change how compute is supplied, not whether resources are finite.

Compute is the part of the system that runs application instructions. That work may run in a fixed pool of servers, containers, or a group that adds and removes servers automatically. That last approach is autoscaling. New capacity takes time to become usable, and adding application copies does not necessarily add database capacity.

Serverless means the provider manages the machines and starts your code when needed; it does not mean no machines or no resource limits exist. An execution environment is one place where a copy of that code runs. Each environment has finite resources. Some may be reused, and some may be new.

Concurrency means how many operations are active at the same time. Limiting concurrency can bound how much work remains active inside an environment or against another component. Available controls and memory signals differ between platforms, so one memory-check recipe is not automatically portable.

If application capacity doubles while database capacity stays unchanged, did the whole system double its useful capacity? Not necessarily. The component that cannot keep up still limits the result.

Diagram walkthrough
  1. Compute is what runs the application instructions.

    Maya asks for a report. The application is the program; compute supplies the resources that execute its instructions. Receiving a message is not the same as doing that work.

  2. The same application can run on servers or in containers.

    The two panels are alternative placements, not a chain of calls. A server pool has separate machines running application copies. Containers provide separate places for programs on a host; they do not remove the host’s resource limits.

  3. Autoscaling changes how many application copies are requested.

    Requests reach A and B. C has been requested, but it contributes no ready capacity yet. Count the copies that can serve now—not the number you asked the platform to create.

  4. A starting copy is not ready capacity.

    C is initializing. A and B still handle the incoming work; C has no incoming request path yet. Adding a desired copy does not instantly relieve the existing servers.

  5. More ready callers do not enlarge the shared database.

    Now suppose C is ready too. All three application copies call the same database. The database is a separate resource: adding an application copy does not automatically add capacity there.

  6. Serverless moves machine management to the provider.

    Your code still runs on machines, inside the provider-managed boundary. The provider starts that code when needed. The word serverless does not mean machines or finite resources have disappeared.

  7. An execution environment is one place where a code copy runs.

    A and B are separate execution environments inside the managed infrastructure. Each box is a place for a copy of your application code, not an unlimited shared machine.

  8. Each environment still has its own finite resource budget.

    Provider-managed execution still has a resource budget. Each environment can run out of its available memory. The strips illustrate finite budgets, not byte measurements or platform defaults.

  9. A later invocation may reuse A or need a new environment.

    The next invocation may reuse environment A, where code has run before, or start in a new environment B. These are alternatives—not two calls made by the application. Never rely on getting A again.

  10. Concurrency counts operations active at the same moment.

    Follow the vertical Now line. A, B and C have all started and none has finished: concurrency is three. The earlier completed operation no longer counts. Concurrency measures overlapping work, not requests per second.

  11. An active-work limit prevents another operation starting when full.

    Choose an illustrative limit of three in this scope. A, B and C are still active, so D cannot start yet. Decide what to do with excess work; moving it to an unbounded waiting area would not solve the resource problem.

  12. Choose the control and the scope your platform actually supports.

    An application-scoped limit covers work in one environment. Protecting a shared dependency also requires reasoning about all its callers. Platforms expose different memory signals and controls; one server middleware recipe is not automatically portable to every serverless runtime.

  13. Two more callers. No larger database.

    A and B were already present; C and D are added. All four paths converge on the same database. We doubled the equal-sized application fleet, not the capacity of every component it depends on.

  14. More compute does not necessarily mean more useful end-to-end capacity.

    If the database already limits completions, more callers do not necessarily produce more reports. They can simply send more work to the same bottleneck. Check the entire request path before treating added compute as added useful capacity.

Content revision: 07c7dd00db17

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

Can adding app servers overload a database that did not grow?

Show the explained answer

Yes. More callers can send more work into the same finite database capacity.

Integration guidance

Use signals and concurrency/admission controls actually available in the selected runtime and platform.

Where the promise stops

Do not assume identical per-request memory observability or middleware support across serverless platforms.

Technical depth & sources

Concepts used here

Implementation detail

Measure ready capacity and per-environment limits separately from desired fleet size. Provider limits and application-owned admission have different scopes.

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.