What Happens When Serverless Compute Scales Faster Than the System Behind It?

One of the most attractive promises of serverless architecture is that you can stop thinking about servers. Traffic increases, the platform creates more execution environments, and capacity contracts again when demand falls. You avoid provisioning fleets for peak traffic, remove a large amount of infrastructure management, and pay much more directly for the compute that actually runs.

That is a real advantage. It also creates a subtle architectural trap: the compute layer may be able to scale much faster than everything it depends on.

AWS Lambda can create additional execution environments as traffic rises, but a relational database behind it still has finite connection and query capacity. A third-party API may allow only a fixed number of requests per second. Redis may look nearly limitless until a hot key or cache-miss storm changes the workload. A legacy service may be perfectly healthy at 50 concurrent calls and collapse at 200.

Highly elastic compute can turn those limits into incidents remarkably quickly.

I encountered the architectural version of this problem while building a serverless backend using API Gateway, Lambda, Redis, database access, payment integrations, and asynchronous workflows. The interesting question was not:

“Can Lambda scale?”

The platform is specifically designed to do that.

The more useful question became:

“How much concurrency can the entire request path safely absorb?”

That changed how I think about serverless systems. Elastic compute is not infinite capacity. It is an extremely effective way to remove one bottleneck—and, in doing so, reveal the next one.

Serverless Removes One Capacity Limit, Not All of Them

Consider a basic API:

At low traffic, the architecture is easy to reason about. Suppose the service receives:

20 requests / second

and each Lambda invocation performs a database query. The database handles the work comfortably.

Now traffic jumps to:

2,000 requests / second

Lambda's job is to respond by creating more concurrent execution capacity. AWS currently documents a per-function concurrency scaling rate of up to 1,000 additional execution environments every 10 seconds, subject to the account's concurrency limits.

That is an extremely useful capability.

But Lambda's scaling system is not asking:

Can this application's database safely accept
1,000 additional clients?

or:

Can the payment provider handle the request rate
those new workers will generate?

Those decisions belong to the application architecture.

This is the core serverless mismatch: the upstream compute tier can increase capacity faster than the dependencies required to complete the work.

A system can therefore become more capable of accepting work while becoming less capable of finishing it.

Concurrency Is the Number That Connects Traffic to Capacity

Requests per second alone do not tell us how many Lambda invocations may exist simultaneously.

A useful approximation is:

Concurrency ≈ request rate × average duration

Suppose traffic reaches:

2,000 requests / second

and an invocation lasts:

250 ms = 0.25 seconds

The application needs approximately:

2,000 × 0.25 = 500 concurrent executions

Now suppose the database behaves safely with:

200 concurrent application connections

If every execution environment creates or maintains its own database connection, the architecture has an immediate mismatch:

The Lambda tier can be perfectly healthy while the database is not.

This relationship becomes even more important when latency changes. If a downstream dependency gets slower, the Lambda invocation lives longer. Because concurrency is related to both request rate and duration, a slower dependency can increase Lambda concurrency even if traffic does not change.

That gives us a feedback path:

dependency slows
→ invocation duration increases
→ concurrency increases
→ more overlapping downstream work
→ dependency slows further

Elastic compute is now amplifying a slowdown instead of hiding it.

Database Connections Are a Finite Resource

Relational database connections make this mismatch especially visible because connections themselves consume finite resources.

In a conventional long-running service, connection growth is fairly predictable:

Application instance
        ↓
20 database connections

Five application instances might therefore imply approximately:

5 × 20 = 100 possible connections

Serverless changes the shape of that relationship:

If each execution environment independently establishes database connectivity, connection growth can begin following Lambda concurrency. A platform capable of creating hundreds of execution environments quickly can therefore become a database-connection generator.

AWS recommends RDS Proxy for production Lambda workloads that create frequent or large numbers of relational database connections. The proxy maintains a managed pool between the functions and the database so client-side concurrency does not translate as directly into the same number of backend database connections.

Conceptually:

That solves an important problem.

It does not solve every database-capacity problem.

A Proxy Fixes Connection Pressure, Not Database Throughput

Suppose the database can sustainably execute:

5,000 queries / second

RDS Proxy may make connection creation, reuse, and pooling substantially more efficient.

It cannot transform that database into:

50,000 queries / second

Those are different limits.

A connection proxy can help with:

too many database clients
connection churn
connection establishment overhead

while leaving these constraints unchanged:

CPU saturation
I/O limits
slow queries
lock contention
transaction contention
storage throughput
memory pressure

The architecture might move from:

Lambda
→ too many connections
→ database failure

to:

Lambda
→ RDS Proxy
→ database CPU reaches 100%

The system improved.

The bottleneck moved.

This distinction matters because architecture diagrams can make proxies look as though they have "solved the database" when they have really solved one particular interaction between elastic clients and a finite database.

Pooling changes how efficiently connections are used.

It does not create unlimited query capacity behind them.

Think in Scaling Curves, Not Architecture Boxes

A typical architecture diagram shows components:

API Gateway → Lambda → Database

For capacity planning, I find it more useful to imagine each component as having its own scaling curve.

For example:

API Gateway:
high elastic capacity

Lambda:
high elastic capacity

Database connections:
finite

Database throughput:
finite

Redis:
finite throughput / memory

External payment API:
rate limited

Email provider:
quota limited

The system is therefore closer to:

The capacity of the request path is not determined by the component with the largest theoretical capacity. It is constrained by the narrowest required resource along the path.

That may differ by operation.

A read-heavy endpoint may be limited by cache behavior.

Checkout may be limited by payment-provider quotas.

A reporting endpoint may be limited by database I/O.

A background import may be limited by one legacy API.

Once serverless removes application-server capacity as the obvious ceiling, these other limits become much more visible.

That is not a weakness of serverless.

It is a reason to model the rest of the system more explicitly.

Reserved Concurrency Can Be a Reliability Boundary

Lambda's reserved concurrency is often introduced as a resource-allocation control: one function should not consume every unit of concurrency available to the account.

It can also act as a bulkhead protecting downstream systems.

Suppose load testing shows that the database remains healthy through:

80 concurrent checkout operations

and begins degrading rapidly beyond that point.

Instead of allowing checkout concurrency to grow until some other resource collapses, the function can be intentionally capped:

Resources:
  CheckoutFunction:
    Type: AWS::Serverless::Function
    Properties:
      ReservedConcurrentExecutions: 80
      Handler: dist/handler.main
      Runtime: nodejs22.x

Now excess demand does not produce unlimited new checkout workers.

It encounters a boundary.

At first, that sounds like a step backward. Serverless is supposed to scale, and we are deliberately stopping it from doing so.

But the real comparison may not be:

80 requests succeed
vs.
500 requests succeed

It may be:

80 requests succeed reliably
vs.
500 concurrent requests overload the database
and almost nothing completes reliably

Reserved concurrency can therefore improve availability by ensuring that one highly elastic tier cannot push a less-elastic dependency outside its safe operating range.

A limit is not always lost capacity.

Sometimes it is protection for useful capacity.

A Limit Can Improve Availability

Suppose a database behaves well at:

100 concurrent operations

begins serious queueing at:

150

and becomes effectively unusable around:

300

Without any concurrency boundary, a traffic spike can create this sequence:

The feedback loop is easy to miss because the first step—Lambda scaling—is technically successful.

Remember:

Concurrency ≈ request rate × duration

If database overload increases function duration, those invocations remain alive longer. Longer-lived invocations increase total concurrency, which creates more simultaneous downstream work, which makes the database slower still.

The loop becomes:

database slows
→ function duration rises
→ concurrency rises
→ database receives more overlapping work
→ database slows further

The architecture does not need a larger compute fleet at this point.

It needs less pressure on the constrained resource.

That is why throttling and concurrency limits should not automatically be interpreted as anti-scalability. They can be the mechanisms that allow the rest of the system to remain available.

Queues Turn Bursts Into Backlogs

For synchronous operations, rejecting or throttling excess work may be necessary.

For asynchronous work, there is another powerful option:

Do not force arrival rate and processing rate to be the same.

Suppose one event creates 100,000 processing tasks.

This design:

asks the compute tier to expose as much parallelism as possible to the downstream database.

But perhaps the database can safely support only:

40 concurrent workers

A queue separates production from consumption:

Now the queue absorbs the difference between:

how quickly work arrives

and:

how quickly the dependency
can safely process it

This is one of the most valuable architectural patterns in serverless systems because it lets the producer remain elastic without requiring every downstream dependency to match that elasticity.

But the queue does not make the dependency faster.

If:

100,000 messages arrive

and processing capacity is:

100 messages / second

SQS does not turn the consumer into:

10,000 messages / second

It converts:

immediate overload

into:

durable waiting

That is usually a much healthier failure mode.

It also changes the operational question.

Instead of asking only whether Lambda is healthy, you now need to know whether the backlog is draining and how long work is waiting.

Metrics such as:

age of oldest message

may tell you more about system health than:

Lambda error rate

The architecture has traded uncontrolled overload for controlled latency.

That is a very useful trade, but it is still a trade.

Queue Consumers Need Limits Too

Adding a queue does not automatically create backpressure if the consumer is still allowed to scale without regard for downstream capacity.

Lambda can scale SQS consumers automatically. That is helpful when the consumer and its dependencies can absorb the parallelism.

It is dangerous when 10,000 queued messages suddenly produce far more workers than the dependency can tolerate.

AWS supports maximum concurrency for SQS event sources for exactly this reason.

For example:

Resources:
  WorkerFunction:
    Type: AWS::Serverless::Function
    Properties:
      Handler: dist/worker.handler
      Runtime: nodejs22.x

      Events:
        Jobs:
          Type: SQS
          Properties:
            Queue: !GetAtt JobsQueue.Arn
            BatchSize: 10
            ScalingConfig:
              MaximumConcurrency: 40

Now the architecture states an explicit capacity assumption:

There may be 1,000,000 messages waiting.

But this queue should not create
more than 40 concurrent workers.

That is backpressure expressed as infrastructure configuration.

It is also a useful separation of concerns:

queue depth
≠
consumer concurrency

A large backlog says a lot of work exists.

It does not mean all of that work should become concurrent work immediately.

Faster Consumption Is Not Always Better

When a queue grows large, the instinct is often:

Increase worker concurrency so the backlog disappears faster.

That works only until the downstream system saturates.

Imagine:

1,000,000 queued jobs

At:

40 workers

the database completes:

4,000 jobs/minute

Now increase consumption to:

200 workers

If lock contention, I/O pressure, cache churn, or transaction conflicts increase enough, total throughput may fall to:

2,500 jobs/minute

while latency grows dramatically.

The important relationship is:

more concurrency
≠
more throughput

at every point on the curve.

Concurrency improves throughput while there is useful parallel capacity to exploit. After the limiting resource saturates, additional concurrency mostly creates queueing and contention.

This means the right worker count is an empirical property of the system.

Load test it.

Do not infer it from the fact that Lambda can scale further.

The fastest way to empty a queue is often not the largest possible number of workers. It is the concurrency level at which the complete pipeline achieves the highest sustainable throughput without destabilizing the dependency.

Synchronous Traffic Needs a Boundary Too

Queues work beautifully for work that can be delayed.

User-facing synchronous APIs still need a way to keep external demand from turning directly into unlimited internal demand.

API Gateway can participate in that control plane using request throttling with rate and burst settings:

AWS's documented API Gateway quotas are not the main point here, and AWS notes that these throttling controls are best-effort targets rather than absolute hard ceilings.

The architectural point is more important:

external demand

does not need to become:

unbounded internal concurrency

Rejecting excess work near the edge may be healthier than accepting it, creating a Lambda invocation, opening database work, calling downstream services, and then failing after several expensive steps.

This is the same load-shedding principle that appears in many distributed systems.

A fast 429 can be much more useful than a slow 500.

Third-Party APIs Are Part of Your Capacity Model

Databases are easy to think about because we own or operate them.

External dependencies are easier to overlook.

Suppose each checkout invocation calls:

Payment API
Email API
Fraud API
Shipping API

Your application might technically support:

1,000 concurrent checkout Lambdas

while the shipping provider contract allows:

100 requests / second

At that point, your serverless architecture can convert a customer traffic spike into an automated denial-of-service attack against your integration partner.

The downstream constraint still belongs in your architecture even though the infrastructure belongs to somebody else.

Possible controls include:

rate limiting
queues
batching
backoff
circuit breakers
reserved concurrency
provider-specific concurrency limits

depending on whether the operation must happen synchronously.

The meaningful capacity question is therefore not:

How many Lambda functions can run?

It is:

How much work can every required dependency
sustain while meeting its latency and reliability target?

Any required external service can become the real capacity limit of your supposedly elastic request path.

Caches Introduce Their Own Failure Mode

Caches usually appear in diagrams as protection for slower systems:

During normal operation, perhaps the cache hit rate is:

95%

That means the database sees only a fraction of total read traffic.

Now imagine Redis becomes unavailable or the cache is flushed:

cache hit rate = 0%

The database may suddenly receive twenty times its normal read load.

Amazon's Builders' Library discusses this class of failure: systems often size downstream infrastructure around expected cache-hit behavior, which means a cold or unavailable cache can redirect enough traffic to overwhelm the dependency the cache was supposed to protect.

Serverless makes that interaction especially interesting because the compute layer may keep scaling successfully throughout the cache failure.

Lambda will happily scale into a cache-miss storm unless some other mechanism limits the work.

That is a useful reminder that caching changes the expected workload seen by the database. It does not remove the need to understand the uncached path.

A resilient architecture should ask:

What happens if the cache hit rate suddenly becomes zero?

not only:

How fast is the service when the cache is warm?

Connection Reuse Helps, but It Does Not Remove Scaling Math

Another important Lambda optimization is creating reusable clients outside the handler so warm execution environments can reuse them.

For example:

import { MongoClient } from "mongodb";

const client = new MongoClient(process.env.MONGODB_URI!);

let connectionPromise: Promise<MongoClient> | undefined;

async function getClient() {
  connectionPromise ??= client.connect();
  return connectionPromise;
}

export async function handler() {
  const dbClient = await getClient();

  const db = dbClient.db("marketplace");

  return db.collection("orders").findOne({
    status: "pending",
  });
}

AWS recommends initializing database clients and SDK clients outside the handler where appropriate so later invocations in the same execution environment can reuse initialized resources.

That is good practice.

But:

one warm execution environment
can reuse one initialized client

does not imply:

500 execution environments
share one client

Scaling still creates additional execution environments.

Connection reuse reduces connection churn and setup work. It does not eliminate the relationship between compute concurrency and downstream capacity.

This is another example of an optimization that should not be mistaken for a capacity boundary.

It makes each worker more efficient.

It does not decide how many workers the dependency can safely tolerate.

Backpressure Is the Missing Concept in Many Serverless Diagrams

A surprising number of architecture diagrams imply the same rule at every arrow:

receive work
→ immediately send work forward

For example:

request
→ API Gateway
→ Lambda
→ database

A more resilient architecture asks:

Can the next component safely accept this work right now?

That question is the essence of backpressure.

In synchronous systems, backpressure can appear as:

429 Too Many Requests
503 Service Unavailable
reserved concurrency
rate limiting
load shedding

In asynchronous systems, it can appear as:

durable queues
consumer concurrency
batch size
processing rate
visibility timeout

Without backpressure, the fastest-scaling component tends to push failure into the slowest-scaling component.

That is especially easy to do with Lambda because Lambda is intentionally good at creating additional compute quickly.

Amazon has described a related distributed-systems principle as putting the smaller service in control. If one system can produce work at enormous scale while another can consume only a fraction of it, letting the larger producer dictate the pace is dangerous.

A queue naturally helps invert that relationship:

The producer remains elastic.

The consumer controls consumption.

The architecture does not require every component to become equally elastic.

It requires the boundaries between differently sized systems to be intentional.

Autoscaling Is Reactive

Another comforting assumption is:

If the downstream system becomes overloaded, autoscaling will catch up.

Sometimes it will.

But autoscaling requires a sequence:

metric collection
→ threshold crossing
→ scaling decision
→ capacity provisioning
→ capacity becoming useful

A burst can arrive much faster than that sequence completes.

AWS resilience guidance notes that automatic scaling can reduce overload conditions while still being unable to react quickly enough to sufficiently sudden changes in utilization.

Lambda is unusually effective at scaling quickly because AWS already maintains the compute platform underneath it.

Your relational database, legacy service, or third-party provider may not have the same property.

That asymmetry is central to the problem.

It is risky to let a component that can increase capacity almost immediately assume that every dependency can respond at the same speed.

Autoscaling remains useful.

It should not be the only protection between elastic demand and a slower-changing resource.

Design Around Safe Concurrency

For each important dependency, I want to know a number closer to this:

database:
safe concurrent operations = 100

payment provider:
safe request rate = 200 RPS

report generation service:
safe concurrency = 20

Redis:
safe throughput under target latency = X

Lambda:
technical concurrency limit >> all of the above

The important word is safe.

The maximum theoretical capacity of a component is not always the operating point where I want production traffic to sit.

The architecture can then encode those assumptions.

For a synchronous database-backed API:

For background work:

These diagrams are much more useful than:

Lambda auto-scales

because they express what the architecture believes the surrounding system can actually sustain.

Capacity assumptions should ideally be visible in infrastructure and operational configuration rather than existing only in somebody's head.

Observe the Whole Request Path

A healthy Lambda dashboard does not necessarily mean the application is healthy.

Imagine Lambda reports:

errors = low
throttles = 0

while the database shows:

connections = 98%
CPU = 94%
query latency = rising

The compute tier looks healthy precisely because the database is absorbing the damage.

I therefore want observability across the full path.

Lambda

ConcurrentExecutions
Duration
Invocations
Errors
Throttles

API Gateway

request rate
4xx
5xx
latency
integration latency

Database

active connections
CPU
query latency
lock waits
I/O
slow queries

Queue

messages available
messages in flight
age of oldest message
dead-letter count

Redis

latency
connections
memory
evictions
cache hit rate

External dependencies

429 rate
5xx rate
latency
timeout rate

The useful dashboard is not:

“Is Lambda healthy?”

It is:

“Is the end-to-end workload staying inside every dependency's safe operating envelope?”

That requires correlating layers.

If Lambda duration increases at the same time database query latency rises, that may explain a concurrency increase without any change in request rate.

If cache hit rate collapses while database CPU spikes, the cache failure may be the real beginning of the incident.

If the queue's oldest-message age grows while error rates remain low, the system may be healthy but falling behind.

Observability should describe the system the user depends on, not merely the component AWS happens to run for you.

Test for the Knee of the Curve

A load test should not merely answer:

At what traffic level does the application crash?

That finds the cliff.

A better test gradually increases load:

50 RPS
100 RPS
200 RPS
400 RPS
800 RPS
...

while tracking:

throughput
p50 latency
p95 latency
p99 latency
database connections
database CPU
Lambda concurrency
error rate

The useful point to find is the knee of the curve.

Suppose results look like this:

Concurrency   Throughput   p99 latency
---------------------------------------
20            1,900/min     180 ms
40            3,700/min     210 ms
60            5,200/min     280 ms
80            6,100/min     450 ms
100           6,200/min     1.4 sec
150           5,500/min     4.8 sec

Maximum throughput may appear around:

100 concurrent workers

but the better operational target could be closer to:

60–80

because latency remains much more stable and the system retains headroom for normal variation.

That is a different optimization target from:

use every available resource

The goal is sustainable throughput.

Load testing the complete path also tells you where to place concurrency limits. If increasing Lambda concurrency from 80 to 120 produces almost no additional useful throughput while database latency triples, you have learned something much more actionable than "Lambda can handle 120 workers."

You have found the beginning of the downstream saturation region.

Serverless Scaling Can Succeed While the Application Fails

Imagine a flash sale.

Traffic jumps.

API Gateway accepts requests.

Lambda creates more execution environments.

CloudWatch shows increasing invocation volume.

From the perspective of the compute platform:

autoscaling worked

Then database connections approach exhaustion.

Queries slow.

Lambda invocations remain alive longer.

Concurrency increases further.

Clients begin timing out and retrying.

More invocations arrive.

The database receives even more overlapping work.

The architecture has demonstrated impressive elasticity while becoming less available.

This is why:

“Did autoscaling work?”

is not the reliability question I care about.

Autoscaling is useful only when the work created by that scaling can actually complete.

Otherwise the platform is simply helping us reach the real bottleneck faster.

What I Would Build

For a serverless backend with constrained dependencies, my baseline architecture would look roughly like this:

The individual AWS services matter less than the capacity boundaries they represent.

Bound synchronous concurrency

API-driven Lambda concurrency should not be allowed to grow beyond what the critical synchronous dependencies can support.

Pool database connections where appropriate

Connection creation and client concurrency should not map one-to-one onto a relational datastore if the datastore cannot sustain that pattern.

Queue work that does not require immediate completion

A durable queue can absorb bursts rather than forwarding every unit of work directly into a smaller dependency.

Limit queue-consumer concurrency

A queue only protects downstream systems if the workers draining it respect downstream capacity.

Respect third-party quotas

Your application's elasticity does not override another provider's rate limit.

Reuse initialized clients

Warm execution environments should reuse database and SDK clients where appropriate, reducing churn without confusing reuse with unlimited shared capacity.

Load test the complete path

Benchmark:

API
→ Lambda
→ cache
→ database
→ external dependencies

rather than testing Lambda as an isolated component.

Shed load deliberately

A controlled 429, throttled invocation, or queued operation can be healthier than admitting work that will only fail after exhausting internal resources.

The theme is consistent: elastic compute should be surrounded by explicit boundaries representing the capacity of less-elastic systems.

The Invariants I Want

For a serverless system, the guarantees I care about are closer to these:

A traffic spike must not create unbounded
downstream concurrency.

A Lambda scaling event must not exhaust
database connections.

A queue consumer must not drain work faster
than the dependency can sustain.

A third-party quota must remain protected
even when application traffic spikes.

Increasing dependency latency must not create
an uncontrolled concurrency feedback loop.

A cache failure must not silently redirect enough
traffic to collapse the underlying datastore.

Excess work should be throttled, queued, or rejected
rather than turning into systemic overload.

Downstream saturation should be observable
before customers discover it.

Those are more meaningful than:

Lambda auto-scales.

because Lambda scaling is a platform capability.

System stability is an architectural property.

The difference matters. AWS can provide the mechanism for creating more compute, but only the application architecture knows how much concurrent work the complete system can safely tolerate.

Final Thought

Serverless platforms are extremely good at removing compute capacity as an obvious constraint.

That is precisely why they make the remaining constraints more important.

Before serverless, a fleet of application servers may have acted as an accidental throttle. Twenty servers with twenty workers each placed a rough ceiling on how much simultaneous work could reach the database. That limit may have been inefficient and inconvenient, but it existed.

Replace that layer with highly elastic compute and the implicit throttle disappears.

That is usually progress.

It also means the architecture now needs an explicit answer to:

How much work should we allow into the constrained part of the system?

Sometimes that answer is reserved concurrency.

Sometimes it is API throttling.

Sometimes it is RDS Proxy.

Sometimes it is SQS.

Sometimes it is maximum consumer concurrency.

Sometimes it is a provider-specific rate limiter.

Sometimes it is load shedding.

And sometimes the correct answer is simply:

No, this dependency cannot safely accept more work right now.

That is not a failure of serverless architecture. It is recognition that scalability is an end-to-end property.

Lambda can scale the compute layer.

It cannot automatically scale every database, cache, legacy service, third-party API, quota, and business constraint behind that compute.

So the real serverless design question is not:

“How far can this function scale?”

It is:

“How far should I allow it to scale before the system behind it becomes the thing that fails?”

That boundary is where serverless architecture becomes reliability engineering.

References

• AWS Lambda Documentation — Lambda scaling behavior. Documents Lambda's per-function scaling behavior and the distinction between concurrency scaling rate and overall concurrency limits.

• AWS Lambda Documentation — Best practices for working with Lambda functions. Discusses downstream throughput constraints, concurrency limits, client reuse, and load testing when dependencies cannot scale as quickly as Lambda.

• AWS Lambda Documentation — Using Lambda with Amazon RDS. Recommends RDS Proxy for production Lambda workloads that create frequent or large numbers of relational database connections and explains the role of connection pooling.

• AWS Compute Blog — Understanding AWS Lambda scaling and throughput. Explains the relationship between concurrency and throughput and discusses using reserved concurrency to protect constrained downstream resources.

• AWS Lambda Documentation — Configuring scaling behavior for SQS event source mappings. Documents maximum consumer concurrency for controlling Lambda scaling from an SQS event source.

• AWS Serverless Application Model — SQS event source. Documents ScalingConfig.MaximumConcurrency for limiting concurrent Lambda invocations created from SQS.

• Amazon Builders' Library — Caching challenges and strategies. Discusses the risk of cold-cache and cache-failure conditions redirecting unexpectedly large traffic volumes toward downstream dependencies.

• Amazon Builders' Library — Avoiding overload by putting the smaller service in control. Explores why a capacity-limited consumer should often influence the pace of work rather than allowing a much larger producer to dictate load.