Why do many web frameworks build or validate the whole object graph at startup instead of resolving dependencies lazily on first use?

## Two moments a wiring error can surface A registration is a promise: *ask me for this key and I will build it*. Nothing verifies the promise until something resolves it. That leaves two candidate moments for a broken promise to become a visible failure: - **at startup**, while the process is still coming up and no traffic has reached it; - **at first use**, when a request arrives, a handler is resolved, and the walk down the graph reaches the missing or cyclic edge. The difference is not academic. The first is a process that never starts. The second is a process that starts, reports itself healthy, accepts traffic and then fails the subset of requests that touch the broken branch — often only the rarely-used endpoint nobody exercised before the release. ## What eager resolution buys Building the graph eagerly turns every wiring defect into a **boot failure**: - a missing binding, an ambiguous binding or a cycle is reported once, with the resolution path that reached it, instead of appearing inside an unrelated request's error; - the failure is attributable — the change that broke it is the change being deployed; - the deploy machinery can react, because a process that exits during startup is the clearest signal a rollout has to work with; - construction side effects that would otherwise happen during a request — opening pools, reading files, checking credentials — happen while nothing is waiting on them; - the first request pays no construction cost, which flattens the latency spike a cold instance shows just after it starts serving. ## What eager resolution costs - **Boot time** grows with the graph, and everything is built whether or not it is ever used. - **Unused branches are built anyway**, including expensive ones guarded by a feature that is off. - **Constructor side effects happen unconditionally**, so a component that connects to something unavailable in this environment can stop the process from starting at all. - **Cycles cannot be papered over**, which is usually a virtue but does remove an escape hatch. - Optional or environment-specific components need explicit handling rather than simply never being resolved. ## Validating without instantiating There is a third option between the two, and it is the one worth knowing about: many containers can **verify the graph** without building it. The check walks every registration, resolves each recipe's parameters to a binding, and reports missing, ambiguous or cyclic edges — but calls no constructor. | Strategy | When wiring errors surface | Boot cost | Side effects at boot | |---|---|---|---| | Lazy resolution | On the first request touching that branch | Lowest | None | | Graph validation only | At startup, for edges the container can see | Small | None | | Eager construction | At startup | Highest | All constructor side effects run | Validation does not see through factory registrations or anything resolved dynamically inside a component, so it narrows the window rather than closing it. Combining validation with eager construction of the expensive-but-essential parts, and laziness for the rest, is a common middle setting. ## When lazy is the right choice Laziness is not merely a weaker default. It is the right answer when: 1. the component is **genuinely optional** — present only when a feature is enabled or a setting is supplied, and never resolved otherwise; 2. construction is **expensive relative to the chance of use**, such as a client for a dependency only one rarely-called endpoint touches; 3. start time is itself a constraint, because instances are created and destroyed frequently and a slow boot is paid over and over; 4. a **cycle** has to be tolerated while it is being designed away, since deferring one side's construction is the usual stopgap. ## The operational reading The reason this question is asked in interviews is that the two strategies fail differently in production, not that one is cleaner. Eager resolution converts a class of defects into a failed deploy — loud, immediate, and attributable to the release. Lazy resolution converts the same defects into errors on a code path, discovered by whoever happens to call it, possibly days later, on an instance that has long since been declared healthy. A pragmatic position: validate the whole graph at startup wherever the container can, construct eagerly whatever the service cannot serve a request without, and keep laziness for components that are honestly optional. Then a wiring mistake is a deploy that does not go out, rather than an incident with a stack trace nobody expected.