Shared Resource Blast Radius: When One Dies, Everyone Dies

Centralization saves resources but concentrates risk. The wall you need to add back is called a semaphore.

Blast Radius Flips

Backpressure Doesn’t Cross Process Boundaries Automatically

• An in-process scheduler only sees resources inside its own process. An out-of-process bottleneck is invisible: no automatic backpressure (GMP scheduler, GOMAXPROCS).
• Bulkhead pattern = deliberately partition capacity so one compartment can’t sink the rest. A shared pool is the anti-bulkhead (it removes the isolation that kept failures contained).
• Rule: when you centralize for efficiency, add back the cap that per-request isolation gave you for free.

Fan-In Math

A per-pod cap only bounds the local sidecar. If the downstream is a shared singleton, N replicas’ caps sum to the actual load. Bound a shared resource with: global limiter (Redis / Envoy), per-replica resource (sidecar), or pull-based queue (busy worker stops pulling).

Role in This OOM

Switching from per-request browser to shared browser saved startup cost, but the blast radius flipped from “one request” to “all in-flight requests.” The Go runtime didn’t know the browser was nearing its limit; no backpressure, goroutines kept opening tabs. Fix: semaphore + 429 at the Go side (the process boundary) (load shedding with TryAcquire).

A shared resource without a cap means the whole system has no cap.

References:

• https://sreschool.com/blog/bulkhead/
• https://oneuptime.com/blog/post/2026-01-25-bulkhead-pattern-go-microservices/view
• https://www.abstractalgorithms.dev/bulkhead-pattern-isolate-capacity-and-failure-domains
• https://medium.com/expedia-group-tech/traffic-shedding-rate-limiting-backpressure-oh-my-21f95c403b29
• https://dev.to/saumya_karnwal/distributed-rate-limiting-five-problems-that-break-your-counters-454

Related: see load shedding with TryAcquire, keep-alive pins retries, and the wrong fix, or go back to the series overview.