How would you set a default component lifetime across a large service, and what should push a component off that default?

## Why a default matters more than the optimum Lifetime decisions are made hundreds of times across a large codebase, mostly by people who are thinking about something else. A rule that is right 90% of the time and costs no thought produces better outcomes than case-by-case optimisation that is applied unevenly and re-litigated in review. So the question to answer first is not "what is best for this component" but "what should a team assume when nobody thought about it". ## The default that works **Process-wide, holding no caller state.** Most components in a service are collaborators: they hold parsed settings, pooled resources and references to other collaborators. Built once, they cost nothing per request and can be reasoned about as constants. The obligation that comes with the default is real and must be stated alongside it: a shared component's mutable fields are shared by every concurrent request. The default is therefore not "singleton" on its own — it is **"singleton and stateless"**, and the second half is the part reviewers enforce. ## What legitimately moves off the default 1. **It carries one request's state.** Identity, tenant, locale, correlation values, an accumulating unit of work — anything whose correctness depends on which request is asking. 2. **It owns a resource that must be released with the request.** A borrowed connection, a buffer, an open transaction. The request scope exists so release is deterministic rather than eventual. 3. **It is cheap, stateful and genuinely per-use.** A builder or accumulator that must not be shared between two callers in the same request is the narrow case for transient. Anything else — expensive construction, wide fan-in, heavy concurrent use — is *not* a reason to shorten a lifetime. Expensive construction argues for sharing. Concurrent use argues for statelessness, not for a new instance per request. ## The cost model | Policy | What it buys | What it costs | |---|---|---| | Everything process-wide | Minimal allocation, simple graph, predictable latency | Hidden shared state; a single stateful field becomes a data-correctness bug under load | | Everything per-request | No thread-safety reasoning; deterministic release | A deep graph rebuilt per request; allocation and tail latency at peak; resources re-acquired constantly | | Stateless default, small scoped set | Both benefits where they matter | Requires a stated rule and a mechanical check to hold the line | The third row is only stable if the "small scoped set" really stays small. Each request-scoped component adds edges that longer-lived components may not hold directly, so the review burden grows with the size of that set, not with the size of the codebase. ## Guardrails, in order of value - **Validate the graph at startup.** Reject any edge from a longer lifetime to a shorter one, with factory, accessor or proxy injection as the sanctioned exception. This converts the most common lifetime bug from a silent production data defect into a boot failure that no deploy can skip. - **Construct eagerly at boot.** Lazy construction defers discovery of the same defects to whichever request happens to trigger them, which means the first evidence arrives in production. - **Publish the scoped set.** A short list of request-scoped components, with a sentence each on why, is a document people actually read. A long list is evidence the default has eroded. - **Make lifetime part of the contract.** For a shared library component, its lifetime constrains every holder, so changing it later is a breaking change even though no signature moved. State it where the component is documented. ## What to measure - Allocation and latency at the tail, not the mean: the cost of a deep per-request graph lands on the slowest percentiles first. - Pool in-use counters returning to baseline between traffic bursts, which is the cheapest live evidence that scopes really close. - The count of request-scoped registrations over time. A number that only grows is the leading indicator that the default is being worked around rather than applied. ## The organisational angle The real failure mode in a large codebase is not a wrong lifetime; it is **an unstated default**, under which every team invents its own and the graph accumulates edges nobody validated. The strongest position to argue is therefore: one written default, one mechanical check in the build, one short list of exceptions, and a bias toward passing request data as arguments rather than scoping more components to carry it.