Take over a backend nobody dares deploy.

The failure signature "it works with a few users, then falls over" is so common because the bug is almost never in one request — it's in how much load a fixed envelope of resources can absorb before the whole process gives out. A service that comfortably handles a handful of visitors can share its time between them because none of them holds a resource for long. The moment one request does heavy, blocking work — parsing a huge payload, running an expensive computation, waiting on something synchronously — it can stall the requests queued behind it, depending on how much genuine isolation the runtime gives each one. At low traffic the queue is short enough that nobody notices; add real concurrency and the same code becomes an outage.

Unbounded memory growth causes the same kind of process-wide failure through a different door. A forgotten event listener, a cache with no eviction policy, or a task that never completes keeps references alive that the garbage collector can't reclaim. Each request adds a little, and for a while it's invisible. Eventually the heap grows large enough that collection pauses start eating into response times for everyone, or the process hits a memory ceiling and gets killed outright — taking every in-flight request with it.

Connections and external dependencies have a matching blind spot. A pool of database connections that never collided at low traffic gets exhausted under concurrency, and requests start hanging on a connection that never frees up. A downstream API that was always fast in testing adds latency and timeouts once real load arrives. None of these show up until the service is actually under pressure — which is exactly why the first move on an inherited backend is to profile it under realistic load and read the metrics, not to guess at the symptom and throw servers at it.