Keep your API fast—even at peak

The application copies return at different times. C is still starting and supplies no ready capacity. Even a running copy also needs working dependencies before it can complete the customer’s report.

Using the earlier equal-cost model, two ready copies provide 200/s while the offered demand is 240/s. A third starting copy adds no ready capacity yet. Actual recovery capacity can be lower while caches or dependencies recover.

A valid cached answer can serve a repeated request without asking the database again. Restart behavior depends on where the cache lives; the following example explicitly considers a cache whose reusable answers are absent.

In this illustration, eighty requests reuse valid answers and twenty each need one database call. Every tile represents ten customer requests, so the C tiles avoid database work and the D tiles require it.

The same 100 customer requests now find no reusable answers. Assuming one database call per miss, every request reaches the database. We did not add customers; we removed the reuse that previously avoided work.

Compare the two cases for the same one hundred requests. Database calls increase fivefold in this simplified example. That does not imply five times the latency, or establish any safe traffic rate for the recovering database.

Use a recovery control that has actually been rehearsed. Reducing or stopping admitted work keeps the recovering system from being immediately overwhelmed by the old demand; the exact mechanism depends on your application.

Do not disable the application’s resource bounds just because it is recovering. Accepted work, cleanup, and refusals still need working space while dependencies and traffic conditions are changing.

Required dependencies must respond and enough application copies must be ready. This is an end-to-end readiness relationship, not a universal process restart order; your dependency structure determines the recovery sequence.

Preparing useful cache entries can reduce later misses, but the preparation itself may query the database. Bound that work against recovering capacity. Some caches remain warm or do not benefit from preparation; warming is not a universal prerequisite.

Follow the highlighted trial step. A real report exercises the useful path through the application and dependencies. The rest of the diagram is a decision guide, not a claim that its success conditions have already been observed.

Check complete reports reaching customers, waiting work clearing, and memory remaining bounded. A health check proving that a process is alive is not enough evidence that its dependencies and real request path can handle the offered work.

A successful trial justifies testing a little more traffic, not jumping to the former full load. Allow meaningful request lifecycles and cleanup to reveal the effect of each change before making another increase.

Follow the alternative branch when waiting or failures grow. Pause the increase or reduce admitted work, then reassess. Capacity changes during recovery, and an earlier successful trial cannot justify blindly continuing the ramp.

An elapsed timer, fixed percentage, or desired replica count is not proof that capacity has recovered. Rehearse admission controls and dependency-specific recovery, including cache behavior and meaningful observation between traffic changes.