In a service's main, how do you decide which collaborators must be reachable at startup and which may start degraded?

## The question behind the question Every service's entry point ends up asking, for each thing it builds: *if this is unreachable right now, should the process exist at all?* Answer "always fatal" and a cache blip crash-loops the fleet. Answer "always continue" and you ship processes that pass health checks and serve errors. Neither default survives contact with production, so the call is made per collaborator, deliberately, and written down. ## The classification **Hard dependencies** are the ones the service's core contract is defined in terms of. For an image-thumbnailing service that is the blob store the thumbnails live in, the listening socket, and the configuration that says where those are. Without them the process can do nothing correct. Failing startup here is not pessimism, it is honesty: a process that exits is a signal the deployment system already knows how to act on — the rollout halts, the previous version keeps serving, and a human sees a clear message naming the collaborator, the address and the underlying cause. **Soft dependencies** are the ones that change how well the service runs, not whether it is right. A thumbnail cache, a metrics sink, a feature-flag source with sane defaults, a warm-up prefetch. The service is slower, blinder or colder without them and still correct. These may start absent — provided you take the two obligations below seriously. The boundary is not always obvious, and the useful test is the read/write asymmetry: a collaborator on the *write* path is usually hard, because degrading means silently losing work; a collaborator on the *read-acceleration* path is usually soft. Ask what a user experiences: an error, or a slower correct answer? ## Obligation one: the degradation must be visible The genuine danger of degraded startup is not being degraded — it is not knowing. Three things make it honest: - A startup log line at warning level naming exactly what is missing and what behaviour changed. - A metric or gauge that says "running without X", so a dashboard can show a fleet coming up degraded rather than one instance. - Readiness that reflects the truth. If "ready" means "will serve correct responses", a degraded-but-correct service is ready. If the missing piece means some requests will fail, it is not, and the process must not claim otherwise merely to make the deploy go green. The anti-pattern is a health endpoint that reports only that the HTTP server answers. That is what turns a half-built process into a successful deployment. ## Obligation two: the degradation must not deform the graph If "cache unavailable" becomes a nil field, every call site grows a check, and one of them will be forgotten. Keep the wiring's shape constant: substitute a stand-in of the same type that stores nothing and always misses, or one that reconnects lazily in the background. The wiring function makes one decision at one line; nothing downstream changes. That also keeps the degraded path warm, because the same stand-in is what a local run or a test uses — a fallback exercised only during an incident is a fallback that has already rotted. ## Obligation three, the one people skip: bound the waiting "Retry until it comes up" is a third answer that looks generous and behaves badly: the process neither starts nor fails, the deployment sits at a partial rollout, and nothing pages. If you retry at startup, bound it — a small number of attempts over a few seconds — and then take the hard-or-soft decision anyway. ## Who owns this and who can overrule it The service owner writes the policy, but it is not theirs alone, because the choice moves cost between teams. Starting degraded converts a crash-loop — loud, caught by the deploy, contained to a rollout — into an elevated error rate or a cold-cache latency spike that shows up on the on-call's pager and in the error budget. On-call can and should force a change after an incident where a degraded start served hours of bad responses, just as product can force one after an outage where a non-essential dependency took the whole fleet down. The engineering answer is to record the decision per collaborator, next to the wiring code, with the reason — "cache: soft, misses only, readiness stays green, alert on running-degraded > 5 minutes" — so the next incident argues with the note instead of re-deriving it at 3am. ## What a good answer sounds like Name the classification test, give one hard and one soft example from a real service, state the visibility obligation, keep the stand-in behind the same type so the graph is unchanged, bound any retry, and finish by saying who is entitled to overrule you and on what evidence. What a weak answer does is pick a side globally — everything fatal, or everything degraded — and defend it as a principle.