Which services standing beside your clusters belong in the continuity plan, and what do you do about the ones you exclude?

## Start with an inventory, not with a policy The recurring failure is not choosing the wrong posture for a companion service - it is never having listed it. So the first move is mechanical: take one publish and one read, and write down everything the client touches that is not a broker. On most estates the list is short and uncomfortable: - the **contract store**, which a producer must reach before it may publish; - on designs that keep cluster metadata outside the brokers, the **coordination service** that holds it; - the service that answers whether a client may connect at all; - whatever resolves the address the client connects to. Each entry on that list is a service that can be healthy while the cluster is gone, gone while the cluster is healthy, or absent from a recovered site entirely. None of them is optional at the moment of a switch. ## Three postures, and what each one really costs | posture | cost | how it fails | when it is the right call | |---|---|---|---| | one shared instance, hosted at one site | lowest; one thing to run and monitor | losing that site stops publishing at the sites that survived, which is the opposite of what the estate was built for | small estates, or a companion whose loss is genuinely tolerable for the length of the outage | | a copy per site | highest; two deployments, and a second copying problem between them | the two instances drift, and nobody notices until a switch needs an entry the local one never received | the companion gates writes and the estate genuinely intends to keep serving from either site | | rebuild on demand from a checked-in definition | low, and rehearsable in a pipeline rather than in an incident | silently incomplete wherever anything is registered at runtime | contents are fully derived from source and the rebuild fits inside the recovery time | The middle row is the one that gets chosen on a slide and abandoned in practice. Keeping two instances of a companion in step is its own copying problem, with its own lag and its own failure modes, and it is invisible until the day it matters. ## The number that actually governs A continuity plan has one honest recovery point, and it is the worst of the parts a producer needs - not the one written next to the cluster. If the stream is copied continuously and its contract store is recovered from a nightly export, the plan's recovery point is the nightly one for every payload whose contract was added since. The same arithmetic applies to recovery time: the wait is the cluster's start, plus the companion's, plus whatever hand-editing stands between them. This is the claim worth making out loud in an interview, because it reframes the whole conversation from "is the cluster covered" to "is the publish path covered". ## What a lead actually signs off 1. **The list**, with an owner per entry - not the messaging team by default, because several of these belong to somebody else. 2. **A posture per entry**, with its cost accepted rather than assumed. 3. **The sequence**, because most of these have an order: something has to be serving before the next thing can read it. 4. **An exclusion register.** A dependency left out deliberately, with the consequence written down, is a decision. One left out by omission is the outage. 5. **A rehearsal date.** Pointing clients at the standby and completing a publish is the only test that exercises the companions at all; a backup job reporting success does not. ## What varies, and why the answer must say so Not every estate has the same companions. Some platforms ship a contract store beside the cluster and some have none, in which case contracts ride with the payload or come from a shared build-time artifact and there is nothing to plan for. Some designs keep cluster metadata in a separate coordination service and others inside the cluster itself. A rented cluster hides several of these behind the provider's boundary, which changes the question from "how do I recover it" to "what has the provider promised about it, and is that number worse than mine?" - and a promise you cannot rehearse is a posture too, just not a comfortable one. ## The honest closing position Most organisations will pay for one shared companion instance and a rehearsal once a year, and that is a defensible answer if it is said out loud with its consequence attached: losing the hosting site stops publishing everywhere until it is rebuilt. The indefensible version is the same arrangement described as full cross-site continuity, because the brokers were the only thing anyone counted.