Clients reach your clusters from inside the network, from a partner network and from laptops — what rule do you set for the addresses each cluster advertises, and what does each extra view cost?

## What is actually being decided The question looks like configuration and is not. It is a standing rule about how many client-facing identities each cluster in the estate has, and that rule outlives the people who set it. The decision is made once, cheaply, and then every member ever added to any cluster inherits it. The underlying fact is simple: **the address a client can use is a property of where the client sits, not of the cluster.** A member that is reachable one way from inside the network may be reachable under a different name from a partner network, and under a third from a developer's machine. Since each member announces an address rather than deriving one from the connection, the operator has to decide, in advance, what each population is told. ## Count populations, not clients A **client population** is a set of clients for which the same set of addresses works. The useful first move is to enumerate them honestly, because the number of views follows from the number of populations and nothing else: - clients inside the same network as the cluster; - clients in a separate network belonging to the same organisation; - clients belonging to another organisation entirely; - clients on engineers' machines, connecting occasionally; - automated jobs that run from somewhere different again. Five populations on paper usually collapse to two or three in practice, and collapsing them deliberately is most of the value of doing the exercise. ## What each extra view costs This is the part that is routinely underestimated, because the first view is free and the second looks like a copy. - Every member needs a **correct address in every view**, and that is true for the whole life of the cluster. - Adding, replacing or moving a member touches every view at once, so the routine operation gets proportionally more places to get wrong. - A view can be wrong for a long time without anyone noticing, because the population that uses it may connect rarely. The failure surfaces at the worst moment, in the hands of whoever needed it least often. - Each view needs something that **exercises** it regularly, or it has no health signal at all. - Every view widens the surface that has to be considered whenever the cluster's shape changes. ## The options, honestly compared | choice | what it buys | what it costs | |---|---|---| | one view, one population | the simplest cluster to operate; one address per member | any client outside that population connects and then cannot work | | one view per population | every population works; failures are localised to one view | per-member addresses multiply; every membership change touches all views | | collapse rare populations into an existing one | fewer views to keep correct | occasional clients must be able to arrive the way that population does | | a platform that answers everything at one address | the question disappears; no per-member addressing to maintain | you accept whatever reachability model that platform offers | ## The rule worth writing down 1. Enumerate populations per cluster, and require a named owner for each one that exists. 2. Give each surviving population exactly one view, and give every member an address in it from the day the member joins — not when someone complains. 3. Cap the number of views deliberately. A new population is a decision, not a side effect of someone needing access this week. 4. Require that every view is exercised by something that connects routinely, so rot is visible. 5. Make membership change the checkpoint: whatever procedure adds a member must add it to all views, or the procedure is incomplete. ## What it forecloses A rule set narrowly is cheap to run and expensive to widen later. If the estate standard is one view, then the first partner integration, the first move of clients into a different network and the first engineer who needs to connect from elsewhere each become a cluster-wide change rather than an onboarding step. If the standard is generous, every cluster carries addressing nobody uses, and the unused views are exactly the ones that will be wrong. There is no neutral answer, which is what makes it a judgment call rather than a setting. The defensible position states the population count, why each one survived the cull, who owns it, and what it would cost to add the next one — and it states which of those costs is paid once against which is paid at every membership change for the rest of the cluster's life.