A dependency review finds several platform services with a single global home sitting under all three of your regions — what posture do you set?

## What a single global home means Large platforms are not uniformly regional. Some capabilities are deliberately global — there is conceptually one of them, it is authoritative, and although it is served from many places its control and its source of truth live in one home. Providers differ in which capabilities they build this way and in how much of the serving path is replicated outwards, but every large platform has some, and a tenant cannot see the internal topology from outside. The consequence is blunt and worth stating in one sentence to whoever commissioned the multi-region design: **three regions cannot be more independent than the least independent thing underneath them.** If all three consult a service with one home, that service's failure is not a regional failure at all. It is a correlated failure across every region you run in, and across every other tenant at the same time. Two overcorrections follow and both are wrong. The first is to conclude that the regions are worthless — they still protect you from power, network, cooling and capacity failures confined to one place, which is the large majority of what actually happens. The second is to conclude that the global dependency only matters if it sits on the request path. A bootstrap dependency is what stops a replaced process from returning, and during a long incident that is the difference between degraded and gone. ## The four postures There are only four honest responses, and the lead's job is to assign one to each dependency rather than to find a single answer for all of them. | Posture | What it costs | When it is right | |---|---|---| | Accept and document | Nothing to build; a written, honest exposure | The capability is rarely used, or the product survives without it | | Move off the hot path | Modest engineering; holding values and bounded staleness | The dependency is consulted often but its answer changes slowly | | Deliberate degraded mode | Product decisions and real work | The capability is central and a reduced product is genuinely useful | | Replace the capability | The most expensive, and ongoing | A small number of dependencies where the exposure is unacceptable | A fifth option — asking the provider to make it regional — is a roadmap request, not a posture. It leaves the estate exactly as the review found it. ## Choosing per dependency Run each finding through the same three questions: - **Where in the lifecycle is it consulted?** On every request, on connect, or only at bootstrap. Bootstrap-only is much cheaper to live with, and is also the one people wrongly dismiss. - **How long can a held answer be trusted?** If the answer changes slowly, holding it with a bounded staleness window converts a hard dependency into a soft one for the length of that window. That is the single highest-value move available and it is usually cheap. - **What does the product do without it?** If the honest answer is 'nothing', you have found either a candidate for replacement or a limit you must state out loud. ## What you owe the business The deliverable that matters is not a mitigation plan; it is an accurate sentence about what the design buys. Something close to: *we survive the loss of a region, we do not survive the loss of these named shared platform services, and for those our exposure is a reduced product for the duration.* That sentence is worth more than any partial engineering, because it is what other people's plans get built on. The failure mode this review exists to prevent is an organisation that believes it is insulated from provider failure because it paid for three regions. Be equally honest about the limits of your own knowledge. You cannot see the provider's internal dependency graph, so the inventory is necessarily incomplete and is built from observed behaviour — what each process contacts before it serves its first request, and what stopped working during the last incident. Treat every provider incident as free discovery and add what it revealed to the list. ## The standard you set The durable output is a rule rather than a fix: a design claiming multi-region resilience must name the shared platform services it depends on and state, for each, what happens when that service is unavailable and which posture was chosen. It is a short table, it takes an hour, and it converts an assumption that nobody wrote down into a decision somebody owns. Pair it with a periodic re-read, because the answer changes as the estate takes on new managed capabilities — each one arriving with its own dependencies that nobody has looked at yet.