Architectural Deep Dive: Why Modern Systems Should Reject "Scope" Concept Inflation — From Captive Dependencies to Closure Primitives

"In software engineering, adding a concept often takes merely dozens of lines of code; but dispelling the cognitive overhead and insidious defects that concept introduces forces the entire engineering organization to pay architectural interest for years."

In architectural discussions, "Scope Isolation" is frequently treated as an inviolable cornerstone of Inversion of Control (IoC/DI) frameworks.

From Spring MVC's @RequestScope and NestJS's Scope.REQUEST, to InferDI's intricate declareScopeInputs and .createScope() methods, "scopes" are often accepted as a sacred, unquestioned dogma.

However, evaluated through the lens of modern system complexity and first principles:

• Why must we isolate states on servers? Where do native ES Module singletons actually fail?
• How does Java Spring actually handle scopes in enterprise production? Why are "hierarchical request container trees" largely a TypeScript cargo cult?
• What hidden architectural price and fatal defects do traditional frameworks pay for hierarchical container trees?
• Why does Path-IoC have the capability—and the architectural obligation—to resolutely reject the concept inflation of scopes?

Starting from the physical runtime realities of concurrent servers, this article deconstructs the misconceptions and fatal traps of traditional scope systems and demonstrates how modern functional topology engines eliminate this historical baggage with orthogonal minimalism.

---

I. Tracing the Problem: Why Native ES Module Singletons Inevitably Fail on Servers

Engineers transitioning from browser frontends to Node.js / Edge backend runtimes often ask a reasonable question:

"JavaScript ES Modules are natively singletons (cached by Node's module system). If I simply write export const logger = new Logger() in a module, isn't it naturally a global singleton? Why do we need a framework to manage lifecycles?"

In single-task environments (such as browser SPAs or CLI scripts), native ESM singletons work adequately. But in modern multi-tenant, high-concurrency server environments (Node.js / Cloudflare Workers), this pattern immediately triggers three fatal failures:

           【State Contamination Under Native ESM Singletons】

     Concurrent Request A (Tenant Alice)        Concurrent Request B (Tenant Bob)
    ┌─────────────────────────┐               ┌─────────────────────────┐
    │ c.req.header['tenant']  │               │ c.req.header['tenant']  │
    └────────────┬────────────┘               └────────────┬────────────┘
                 │                                         │
                 ▼                                         ▼
    ┌───────────────────────────────────────────────────────────────────┐
    │               ESM Global Singleton: export const logger           │
    │  logger.tenantId = "Alice"  <── Race Overwrite ── logger.tenantId = "Bob"
    └───────────────────────────────────────────────────────────────────┘
                                   │
                                   ▼
          🚨 Critical Security Incident: Tenant Alice reads Bob's data!

1. Failure Mode 1: State Leakage & Race Conditions in Single-Threaded Event Loops

Node.js concurrently interleaves thousands of HTTP connections over a single-threaded Event Loop:

• Request A (Tenant Alice) arrives, and its execution pipeline writes tenant metadata into the global singleton: logger.tenantId = "Alice";
• During asynchronous I/O suspension, concurrent Request B (Tenant Bob) arrives, overwriting the field with "Bob";
• When Request A's I/O callback resumes and emits audit logs or executes database queries, the global singleton holds Tenant Bob's security context!
• Conclusion: Native ESM singletons represent coarse process-level lifecycles. Without structural isolation, they cannot safely hold request-scoped contextual state.

2. Failure Mode 2: Asynchronous Initialization Deadlocks (The Top-Level Await Trap)

When an infrastructure resource (such as a database connection pool or remote configuration client) must perform an asynchronous handshake at startup:

• Native ESM forces the use of Top-Level Await (export const db = await connect());
• If network jitter, DNS resolution latency, or credential expiration occurs, the entire Node.js process freezes during the import phase, preventing runtime graceful degradation or retry policies.

3. Failure Mode 3: Test State Contamination

In test runners like Vitest or Jest running multiple suites concurrently, dozens of test files executed within the same worker thread reuse the underlying Module Cache:

• State mutations performed by one test contaminate subsequent tests like a contagion;
• To isolate state, developers resort to invasive hacks like vi.mock() or jest.resetModules(), rendering the test suite fragile.

These physical failure modes establish that server runtimes have a strict, non-negotiable requirement for Request-Level Isolation.

---

II. Historical Context & Epistemic Gaps: Spring Reality vs. TypeScript Cargo Cult

Before evaluating solutions, we must clarify a persistent misconception in software engineering: Hierarchical request container trees are neither a standard pattern in production Java Spring, nor a universal law of software design.

1. The Reality of Spring Core: 99.9% Pure Singletons

Engineers outside the Java ecosystem often assume Spring governs concurrency via intricate hierarchical scope trees. The operational truth is the exact opposite:

• The Core Container is Exclusively Singleton: In Spring Core (spring-core / spring-beans), the only foundational scopes are singleton (default) and prototype (new instance per lookup). Request scopes do not exist in the core container;
• Request Scope is an Ancillary Web Extension: The request and session scopes are web-aware additions introduced strictly in spring-web / Spring MVC;
• Virtually Unused in Enterprise Production: Over two decades of enterprise Java / Spring Boot production, mature engineering teams almost never use @RequestScope. Almost every @Service, @Repository, and @Controller is a pure, stateless singleton.

2. Why Java Naturally Avoids "Hierarchical Scope Containers"

Java server architectures safely rely on pure singletons because the underlying runtime provides physical concurrency isolation out of the box:

• Thread-per-Request Physical Isolation: Traditional servlet containers (Tomcat, Jetty) or modern Project Loom Virtual Threads assign a dedicated OS/virtual thread to each incoming HTTP request. Each thread maintains its own isolated call stack frames. Stateless singleton methods operate purely on stack variables and method arguments, completely insulated from concurrent requests;
• ThreadLocal for Implicit Contexts: When cross-cutting state must be accessed across service boundaries without pollutive parameter drilling, Java engineers utilize ThreadLocal (e.g., Spring Security's SecurityContextHolder, Logback's MDC), which is bound to the thread and wiped clean in a servlet filter upon request completion;
• Even with @RequestScope, Spring Never Rebuilds Container Trees: In the rare instances where @RequestScope is declared, Spring never creates a child ApplicationContext per request. Instead, it generates a CGLIB dynamic proxy singleton that delegates method calls at runtime to RequestContextHolder.currentRequestAttributes(), which is backed internally by a ThreadLocal.

3. The TypeScript Ecosystem's "Cargo Cult" and the Hierarchical Tree Misstep

When the TypeScript / Node.js community attempted to adopt IoC patterns, a severe architectural disconnect occurred:

• The Concurrency Gap: Node.js executes on a single-threaded Event Loop. Thousands of requests interleave asynchronously over the same thread stack via async/await. Node.js lacks native thread stacks and historically lacked reliable ThreadLocal mechanics (until recent additions like AsyncLocalStorage);
• Blind Emulation: Certain frameworks assumed that because Spring is widely used, "enterprise IoC requires Request Scopes". Lacking thread stacks and dynamic bytecode generation, they adopted a cumbersome brute-force approach: deriving and allocating a hierarchical container sub-tree in memory for every HTTP request!

                   【Classical Hierarchical Container Tree】

                     ┌─────────────────────────────┐
                     │   Root Container            │
                     │   Lifecycle: Singleton      │
                     │   Owns: DB Pool, Redis, MQ  │
                     └──────────────┬──────────────┘
                                    │
                                    │ .createScope(inputs)
                                    ▼
                     ┌─────────────────────────────┐
                     │   Child Container (Scope)   │
                     │   Lifecycle: Scoped         │
                     │   Owns: User, Order, Context│
                     └─────────────────────────────┘

To maintain these hierarchical container trees, frameworks had to introduce an avalanche of artificial concepts, causing severe Concept Inflation:

1. Lifecycle Annotations & Decision Fatigue: Developers must continually categorize and enforce @Scope('singleton'), @Scope('scoped'), and @Scope('transient') across their classes;
2. Scope Input Slots: To pass runtime HTTP contexts down to child scopes, pure type-inference frameworks like InferDI were forced to invent methods like declareScopeInputs<T>() purely to appease the type checker;
3. Catastrophic Throughput Degradation: In frameworks like NestJS, marking a single service as Scope.REQUEST forces all upstream consumers to bubble up into request-scoped instantiation, causing massive GC pressure and slashing throughput by up to 70% (an issue explicitly flagged in NestJS official documentation);
4. Disposal Contracts & Teardown Registries: The root container must maintain tracking registries to manually trigger teardown hooks across child instances upon HTTP response termination.

---

III. The #1 Ghost Defect of Traditional Scopes: The Captive Dependency Trap

The fatal vulnerability of hierarchical containers is not merely verbose APIs, but an inherent architectural contradiction: Captive Dependencies.

What is a Captive Dependency?

In a hierarchical container, a longer-lived service must never inject a shorter-lived service.

              🚨 Captive Dependency Architectural Defect

┌────────────────────────────────────────────────────────────────────────┐
│ Root Singleton Service: OrderMetricsService (Lifecycle: Singleton)     │
│                                                                        │
│   constructor(private requestCtx: RequestContext) {} // ❌ Fatal bug!  │
│                                                                        │
│   Retains Reference: ────────────────────────────────┐                 │
└──────────────────────────────────────────────────────┼─────────────────┘
                                                       │ Permanently Captured!
                                                       ▼
                             ┌───────────────────────────────────────────┐
                             │ Scoped Instance: RequestContext (Alice)   │
                             │ Should be GC'd on HTTP 200, but held by   │
                             │ the singleton forever!                    │
                             └───────────────────────────────────────────┘

• An engineer writes a global metrics service OrderMetricsService (Singleton);
• In its constructor, they inject the current request's RequestContext (Scoped);
• Disaster Strikes: Because singletons are instantiated only once during process lifetime, this service permanently captures and retains a reference to the very first request's context!
• Consequences:
  1. Across subsequent hundreds of thousands of requests, the singleton continues operating with the stale identity of user Alice;
  2. Memory linked to Alice's request cannot be collected by V8's garbage collector, resulting in insidious memory leaks and multi-tenant security breaches.

The Defense Tax: Lifetime Guards

To prevent developers from making this error, frameworks are forced to run graph-traversal algorithms during boot or registration to validate dependency lifecycles:

• If a longer-lived service references a shorter-lived dependency, an exception is thrown;
• Developers are forced to halt feature development, trace convoluted dependency trees, and resort to anti-patterns like ModuleRef or Service Locators that defeat the very purpose of Inversion of Control.

---

IV. The Raw Arithmetic of Real Systems: The 1% Exception vs. The 99% Norm

Before inventing a conceptual abstraction, one must examine the physical reality of production applications.

In a representative mid-to-large full-stack or microservice application comprising 200 modules, we rigorously categorize the actual lifecycle requirements:

       Industrial Lifecycle Distribution (Occam's Razor Audit)
┌───────────────────────────────────────────────────────────────┐
│ 99% of Modules (~195): Stateless Domain Logic                 │
│ Controller / Service / Handler / Validator / Form / Component │
│ ➔ Pure data transformation and business orchestration         │
│ ➔ An ephemeral closure per HTTP request is inherently safe,   │
│   preventing cross-tenant data leaks by design                │
└───────────────────────────────────────────────────────────────┘
┌───────────────────────────────────────────────────────────────┐
│ Only 1% of Modules (~3 to 5): Heavy Stateful Resources        │
│ Database Connection Pool(1) / Redis Client(1) / MQ Client(1)  │
│ ➔ Truly long-lived TCP socket pools that must persist across  │
│   requests within the process memory space                    │
└───────────────────────────────────────────────────────────────┘

Empirical data reveals an undeniable truth:

• The heavy resources that genuinely require "process-level singleton persistence" represent a miniscule 1% of the codebase (typically 3 to 5: DB pool, Redis, MQ);
• The remaining 99% of business modules are entirely stateless logic!

Traditional IoC frameworks commit an architectural overreach: To accommodate the caching requirements of that 1% of database connection pools, they force an entire "scope system" onto the codebase, compelling the entire engineering organization to manage lifecycle tags and fight captive dependencies across the other 195 business modules.

Forcing 99% of stateless code to pay a lifetime cognitive tax for a 1% edge case is fundamentally flawed architecture.

---

V. Path-IoC's Minimalist Solution: Per-Request Pristine Meshes + Closure Memoization

Technically, implementing hierarchical containers and scope tags in Path-IoC would be trivial (nested map lookups). Yet Path-IoC resolutely rejects this concept inflation, delivering an orthogonal solution rooted in pure functional closures and microsecond topological execution:

            【Path-IoC's Minimalist Lifecycle System】

                 Inbound HTTP Request
                          │
                          ▼
  ┌───────────────────────────────────────────────────────┐
  │ Isolated Mesh: createModularContainer({ ctx })        │
  │ Latency: 21.2µs (Static graph pre-compiled, ~0 CPU)   │
  │ State: 99% of business modules are purely isolated    │
  └───────────────────────┬───────────────────────────────┘
                          │
                          │ Accessing the 1% heavy resource?
                          ▼
  ┌───────────────────────────────────────────────────────┐
  │ Closure Primitive: export const main = memoizeModule()│
  │ Behavior: Returns stable memory reference across      │
  │ requests with built-in poison-pill recovery           │
  └───────────────────────────────────────────────────────┘

1. Default Philosophy: Universal Per-Request Isolation (Zero Scope Tags)

In Path-IoC, every inbound HTTP request instantiates an independent, clean ModularContainer:

app.all("*", async (c) => {
  // Graph compilation occurs once at boot; request instantiation takes just 21.2µs!
  const container = await createModularContainer({ requestContext: c });
  return container.apiAggregator();
});

• Eliminating State Leaks at the Root: All business modules and contextual parameters operate cleanly within request boundaries without scope annotations;
• Immunity to Captive Dependencies: Because the container itself is request-scoped, there is physically no longer-lived container to capture request instances. The captive dependency problem is dissolved mathematically.

2. For the 1% Heavy Infrastructure: Closure Memoization (memoizeModule)

For the rare resources requiring process-level persistence (DB connection pools, Redis clients), Path-IoC rejects hierarchical containers in favor of JavaScript's first-class functional closures:

// src/modules/db-pool/index.ts
import { memoizeModule } from "@path-ioc/core";

// memoizeModule handles cross-request caching, concurrency defense, and error recovery
export const main = memoizeModule(async () => {
  const pool = new DatabasePool();
  await pool.connect();
  return pool; // Executed once per process; safely reused across requests!
});

• Local Explicit Control: Only infrastructure engineers maintaining low-level database modules ever touch memoizeModule;
• Zero Business-Layer Overhead: The remaining 195 business modules (such as order-service) simply declare dependencies on "dbPool", destructure it, and execute—entirely oblivious to whether it is a singleton or ephemeral instance.

---

VI. Comparative Architecture Matrix

Dimension	Classical OOP DI (NestJS / InferDI)	Path-IoC (IoC-DL Mesh)
Isolation Model	Hierarchical Container Trees	Default Per-Request Isolation + Closure Memoization
Lifecycle Annotations	Mandatory @Scope() / 'singleton' / 'scoped'	Zero Scope Tags (Business code is 100% pure functions)
Context Ingestion	Complex slots like declareScopeInputs	Passed directly as plain object literals: { requestContext: c }
Captive Dependency Risk	Severe (Singletons capture request context, leaking tenant data)	Physically Immune (Dissolved by universal per-request isolation)
Cognitive Burden	Heavy (Continuous lifecycle decision-making across all classes)	Near Zero (Write standard pure functions; no private concepts)
Edge Computing Fit	Poor (Relies on long-lived stateful container trees)	Ideal (Microsecond cold-starts, natively tailored to Workers)

---

💡 Conclusion: Occam's Razor and Architectural Restraint

Albert Einstein famously observed: "Everything should be made as simple as possible, but not simpler."

Frameworks degenerate into bloat because their first instinct when encountering an operational requirement (such as scope isolation) is "to introduce another abstraction layer (concept inflation)."

Path-IoC adheres strictly to Occam's Razor:

"Entities should not be multiplied beyond necessity."

When 21.2µs topological instantiation reduces the cost of spawning a fresh container to near-zero, traditional hierarchical scope trees, lifetime guards, and input slots lose their physical reason to exist.

Eliminating the concept of scopes is not a compromise in capability—it is a conscious architectural liberation that returns cognitive clarity to developers.