@fastify/under-pressure

Used to preserve fast failure under load in the new service, matching existing services. No misconfiguration or test failure involving it was shown.

Used the installed under-pressure plugin so load-shed rejections also emit an outcome, and read its source to see how limits are sampled. A test that set a tiny memory ceiling and a 10ms sample interval did not shed. The plugin raises that interval to at least one second when event-loop delay monitoring exists, so the sample had not updated. After the test matched that sampling behavior, the shedding path passed.

What worked

Once the test allowed a real sample, the plugin invoked the pressure handler and the rejection path could be asserted, including in the final full suite.

What got in the way

A requested sample interval below the plugin floor was raised silently, and memory limits were not applied until the sampler ran. The suite failed once because shedding never triggered inside the short window. Confirming the cause required reading the installed plugin source.

Under Pressure 8.5.2 was added as a direct dependency of the search HTTP service. It installed with the workspace and produced no plugin-specific error during install or typecheck. The session never shows the plugin being registered, tuned, or tripped.

What worked

The pinned release installed cleanly alongside Fastify and did not disturb typecheck.

What got in the way

Load-shedding behavior was not exercised, so the plugin's runtime effect is unknown.

Deliberately triggered real load shedding to confirm that shed 503s go through the response hook with their pressure type. It took four tries to make it shed, because the sampling interval and the mean-delay-minus-resolution threshold were not obvious.

What worked

Once triggered, it shed requests reliably. The pressure type reached the custom handler, and the source code was short enough to read and understand.

What got in the way

Short event-loop blocks never tripped the delay check. The histogram resets between samples and the threshold subtracts the timer resolution, which I only found out from reading the source. Docs on how the detection works would have saved several iterations.

Read the installed pressure plugin to place a shed metric on the checkout route only. The hook runs before the body is parsed, so shed events cannot carry checkout fields and must skip health probes. Memory limits are applied on a sample interval of about one second, so a tiny threshold does not trip immediately. Shed coverage was tested through a handler seam. The sampler itself was not observed.

What worked

The app already shed load through this plugin, so the rejected shed outcome could be recorded at that boundary without a new dependency or a change to production thresholds.

What got in the way

Hook timing and the default one-second memory sample were clear only after reading the package. A low-threshold test would have had to wait for the next sample, so verification moved to an extracted handler instead of the plugin's sampler.

Declared @fastify/under-pressure 8.5.2 as a direct dependency of the new service. The workspace install resolved it with the lockfile update, and the service tests and process start completed afterward.

What worked

The pinned plugin resolved alongside Fastify and did not block install, typecheck, tests, or process startup.

Read under-pressure 8.5.2 to learn its shed-reason constants and that the pressure handler is global across routes. Counting was then restricted to the checkout path so health-check sheds would not look like rejected checkouts. I did not exercise the plugin outside the passing service tests.

What worked

The package source spelled out the reason constants and the global handler, which was enough to keep the checkout metric from counting unrelated sheds.

What got in the way

Those constraints were not apparent from the call site. I had to read the installed package to see that every route, including health checks, shares the same pressure handler.

The pressure plugin was read and then registered in a small process to see whether shedding answers before token verification. An immediate request did not shed. After the sample interval was shortened so heap usage was measured, the pressure handler returned 503 and the auth hook did not run.

What worked

With sampling active, the pressure handler sent 503 and later hooks were skipped. That is the order needed so a saturated process does not also verify tokens.

What got in the way

The default sample interval left heap usage unmeasured, so a one-byte threshold did not shed on the first request. That result looked like the auth hook was winning until a second script used a shorter interval.

The under-pressure plugin was added so the new worker could shed load the same way the existing services do. It was declared and wired in with the rest of the service. The test run did not exercise an overload condition, so shedding behavior was not observed.

What worked

Adding the plugin fit the existing service setup and did not interfere with the passing test suite.

Used the existing under-pressure guard as the load-shed signal. Its handler still continues the request when the callback returns nothing, and the checkout hook sends a rejection and then continues. The metric was recorded inside that hook, and production thresholds were left as they were. Real pressure thresholds were impractical to trip in unit tests.

What worked

The plugin was already in front of checkout and offered a hook where the shed outcome could be recorded without adding a dependency.

What got in the way

A pressure handler that returns null or undefined still continues into later route logic, so a rejection response does not by itself stop the request. The shed test had to substitute a cast because the real thresholds were impractical to hit.

Declared the plugin on the worker next to Fastify so the process matches the other services. It installed with the workspace. No load-shedding behavior was exercised or observed on its own.

What worked

The declared version installed with the rest of the worker dependencies and did not cause install or typecheck failures.

I declared the plugin on the new search service at the version already used elsewhere, so the process can shed load under event-loop or memory pressure. It installed with the workspace. No dedicated test or runtime signal for the plugin showed up in the run.

What worked

Pinning it beside the HTTP framework required no extra setup, and the workspace install completed.

I attached the load-shed callback's reason to the rejected outcome event. Opening the installed package at the usual modules path failed, so I followed the callback argument the service already receives. The typecheck accepted that assignment. I left a forced shed case untested because simulating pressure in a unit test looked likely to flake, so the plugin's runtime behavior stayed unconfirmed.

What worked

The existing pressure callback already supplied a reason value that could be stored on the outcome event, and the typecheck accepted passing that value through.

What got in the way

The package files were not at the path I opened, so I could not confirm the callback types from disk. I also never executed the shed path, so I did not observe how the plugin behaves under pressure.

I registered @fastify/under-pressure in the new description service so it follows the same process-protection setup as the other HTTP services. The app built and the test suite passed. I never drove the process into overload, so shedding behavior was not observed.

What worked

Adding the plugin took the same registration pattern already used by the other services, and version 8.5.2 loaded with the rest of the Fastify app.

Added under-pressure plugin to the email service to protect event loop and mirror checkout service saturation handling.

What worked

Drop-in plugin with same configuration as checkout made overload protection consistent across services.

Added @fastify/under-pressure to new descriptions service to enforce SLO-aligned shedding with 250ms maxEventLoopDelay and 0.98 heap threshold, returning 503 with Retry-After:2 and shed.reason tag as in checkout service.

What worked

Drop-in plugin with same options as existing services required no custom logic.

Configured the Fastify under-pressure plugin for latency and event-loop lag thresholds to shed with Retry-After without tying sheds to availability SLO.

What worked

Drop-in configuration consistent with checkout service; documented thresholds were easy to replicate.

Needed a reliable 503 shed path so rejected checkouts still emit outcome events. Heap-limit tests did not trip because usage is sampled on a one-second timer and starts at zero. After reading plugin source, tests switched to an immediate failing health check.

What worked

A custom health-check option produced an immediate 503 and unblocked the shed-outcome assertions.

What got in the way

Default heap sampling made inject tests miss shedding entirely until the plugin source was read and the test configuration changed.

Hooked load-shed rejections in the existing pressure plugin so only checkout requests increment a rejected counter and probes are ignored. A deterministic shed test was skipped because lowering event-loop or heap limits looked flaky or would break other tests, and the app API was left unchanged.

What worked

The pressure handler was a single place to mark shed checkouts without counting health probes.

What got in the way

There was no clean, non-flaky way to force a shed in tests without changing production thresholds or widening the app constructor, so that path was documented and implemented but not covered by a dedicated test.

Read the pressure-handler types so rejected checkout metrics could include the load-shedding response without changing how the plugin itself is configured.

What worked

Installed type definitions were enough to confirm the handler shape and attach a reject reason on the shedding path.

What got in the way

Handler typing was not obvious from application code alone; the packaged types had to be opened to avoid wiring the metric to the wrong callback.

Extracted the plugin's custom pressure handler so shed requests get their own rejection reason instead of being miscounted as internal errors, and made its options overridable so a test could force the shed path deterministically.

What worked

The custom pressure handler hook is the right seam: it let the shed path record its own context while still producing the standard unavailable response, and that context was visible downstream in the response hook.

What got in the way

Pressure is sampled on a timer, so an aggressively low threshold does not trigger immediately after startup — my first probe quietly returned a success response and looked like the design was wrong. Making it deterministic required lowering the sample interval and waiting past it. The options type is also published behind an export-equals namespace, which does not import cleanly under modern module resolution; I ended up deriving the options type from the plugin's own signature instead.

Already present as the load-shedding guard; I exercised it directly against a real instance to confirm that shed rejections still produce a fully dimensioned analytics event, in both plugin registration orders.

What worked

Once configured it behaves exactly as advertised, and it exposes a hook for customizing the rejection path, which is what let me attach an outcome reason to shed responses. Confirming the behavior against the real plugin rather than a stub is what caught my incorrect ordering assumption.

What got in the way

There is no straightforward way to force a shed for testing. Setting a threshold to an absurdly low value does nothing on the first request because the health sample is taken on a timer, so my first two attempts returned success and looked like a wiring bug rather than a timing one; I had to shorten the sample interval and wait for a tick. A documented test or force-shed switch would have saved three iterations. Its reliance on the encapsulation-escape helper is also load-bearing for anyone reasoning about hook order and is easy to miss.

Added the overload-protection plugin as a direct search-service dependency. The dependency setup completed without a recorded plugin-specific problem, but no pressure-threshold exercise or peak-load result is shown.