Service Startup as a Declared Dependency Graph

#Abstract

Service startup expressed as a sequence of statements is correct by arrangement and degrades under maintenance, because the ordering constraints are implicit in the order of lines. This note describes startup as a declared dependency graph, gives the three properties that follow, and identifies the two classes of failure the model does not address.

#The failure mode

An initialisation function opens a database, then a cache, then a message consumer, then starts an HTTP server. The order is correct because somebody arranged it correctly. Nothing records why line nine precedes line ten.

A later change inserts a component at a plausible position. The service now accepts traffic before a dependency is ready. Under light load this is invisible, because the first request arrives after everything has settled, so the defect ships and appears under load.

#Construction

Each component declares the components it requires. The container computes a start order by topological sort, starts in that order, and reverses it for shutdown.

The property that matters is not that a particular order is chosen. It is that the constraint is declared next to the component that holds it, so a new component states its own requirement and the order is derived rather than maintained.

This is the module criterion applied to time [1]. The knowledge of what a component needs belongs to that component, and a central ordered list is that knowledge stored in the wrong place.

#Three consequences

Failures name their cause. A component that cannot start reports which component it was and which dependency it was waiting on, instead of producing a nil dereference several layers below the point where the actual cause was forgotten.

Shutdown is correct without separate effort. The reverse of a derived order is a derived order. Incorrect shutdown ordering produces connections closed underneath in-flight work and consumers handing work to components that have released their resources, which is a well documented source of failure during deployment [2].

The order is inspectable. It can be printed with timings. A service taking eleven seconds to start becomes a question answerable by reading a list.

#What the model does not address

Readiness over time. A component can start successfully and remain unable to serve, because a pool is empty or a cache is cold. Startup ordering and readiness reporting are separate mechanisms and both are required, which is why orchestrators distinguish liveness from readiness [4] [3].

Cycles. The model detects them, which is better than deadlocking, and detection is not resolution. A cycle indicates two components contending for one decision, and breaking it is a modelling exercise [1].

#Evidence

The construction was implemented twice, five years and one language apart, in a Rust framework in 2021 and a Go framework in 2025. The second implementation was written from the first design without revisiting it, which is weak evidence that the model is not an artefact of one language's constraints.

It is weak because the same author wrote both. An independent implementation would be worth more, and I do not have one.

#Limitations

No quantitative claim is made here. The assertion that startup ordering is a common source of deployment failure rests on my own experience across four frameworks, and it is exactly the sort of claim that accidental difficulty tends to attach itself to [5]. A study of deployment incidents classified by cause would test it.