Dependency Ordering: Starting Dependent Resources in Sequence

Dependency ordering is the practice of starting and stopping related cloud resources in a set sequence, so that each component comes up after the things it depends on and goes down before them. A typical web environment has three layers: storage and databases at the bottom, compute such as VMs or node pools in the middle, and application services on top. Started all at once, the application layer can boot before its database accepts connections, fail its health checks, and restart or page someone. Started in sequence, the same environment comes up cleanly.

Start forward, stop in reverse

The start sequence goes bottom-up: data stores, then the compute they run beside, then the services that call them. The stop sequence is the mirror image: stop the application first so it is not writing to a database that is disappearing underneath it, then compute, then the data stores. Stopping in reverse also means no service spends its last minutes logging connection errors that someone later investigates.

Ordering is not the same as waiting

There are two ways a tool can implement a sequence:

1. Time spacing. Actions are issued in order with a fixed gap between them. Nothing checks whether the previous resource actually finished starting.
2. Health gating. Each step waits until the previous resource reports that it is available, then proceeds.

Time spacing is simpler and predictable, but it only works if the gap is longer than the slowest start you will see. Health gating adapts to slow starts but needs a definition of “ready” for every resource type.

ZopNight uses time spacing. A resource group runs in tiers: storage first, then databases, then compute, then apps, reversed on stop, with 30 seconds between tiers. You can change a resource’s tier and set a start or stop delay per resource. The sequence is coordinated when the group’s schedule starts or stops it as a unit. It does not wait for a resource to reach its target state before the next one begins; a plan that gates on success is not built. The delays are therefore the safety margin, and they are yours to size.

How to size the delays

• Measure, do not assume. Start the environment manually a few times and record how long each data store takes to accept connections. Your own start times are the only reliable input; a figure from another team’s environment is not a substitute.
• Add margin to the slowest run you saw, not the average.
• Give the stop sequence its own delays. Draining connections from an application takes less time than a database recovery on start, so the two directions rarely need the same gap.
• Re-measure after resizing. A larger instance class or a restored snapshot can change start time.

Make the application tolerant anyway

Ordering reduces failures; it does not remove them. Give applications connection retry with backoff so a database that is a few seconds late causes a delay, not an outage. On Kubernetes, an init container is a natural gate: init containers run to completion before the Pod’s app containers start, and each must succeed before the next begins, so an init container that waits for the database port holds the application back until the dependency answers.

Provider details that affect ordering

Some resources constrain what you can sequence. An Amazon RDS DB instance that has a read replica, or is one, cannot be stopped, so an environment containing one needs a different plan for its database tier. RDS also restarts a stopped instance automatically after seven consecutive days, which matters for environments left off over a long holiday.

For grouping the resources that share a sequence, see resource groups; for choosing when the sequence runs, see cloud scheduling best practices. Database-specific scheduling is covered on the RDS schedule page.