Teams keep asking to address individual replicas directly instead of through the service's virtual address — how do you decide which requests to grant, and what do you require of the ones you do?

## Two different questions hide behind one request "Let me address replicas directly" is asked for two very different reasons, and the whole decision is telling them apart. - **"I need a particular member."** The work is bound to one instance: peers forming a group among themselves, a caller that must reach the instance that holds a given piece of state, a collection path that must read each member separately rather than a random one, or an administrative call aimed at one instance under investigation. Here the virtual address is genuinely the wrong tool — it deliberately hides which member you reach, which is exactly what this caller cannot have. - **"I want better behaviour than the platform's dispatch gives me."** The team wants an ordering, an affinity, or a spread they think they can do better. This is not an addressing requirement at all; it is a routing or balancing requirement wearing an addressing costume, and granting it hands one team a permanent copy of a problem the platform already owns. The first is a small, checkable set. The second should almost always be refused, because the cost lands on the team's future on-call rather than on the person asking today. ## What the caller signs up for Granting direct addressing means the caller has taken over the job the platform was doing. Make that explicit and reviewable, because it is invisible in the code afterwards: - **Re-read membership.** The set changes constantly, so the caller must resolve again rather than keep the first answer for the life of the process. - **Treat a listed member as possibly unusable.** Depending on the mode, the answer may include members that are not currently ready, so the caller needs its own handling rather than assuming everything it sees can serve. - **Spread its own calls.** With no dispatch in the path, an evenly loaded replica set is now the caller's responsibility. - **Drop members that are gone**, and not retry into an address that has stopped answering — remembering that a released address can later belong to a completely different workload. - **Own retries and timeouts**, including the question of which work is safe to repeat. - **Re-open connections periodically**, because pinning is now entirely in its hands. If a team cannot say how it does those six things, the honest answer is that it is asking for direct addressing and expecting the platform's guarantees anyway. ## Keep both, and keep the exception narrow The two modes are not mutually exclusive, and the standard worth setting is to have both in front of the same replicas: 1. The stable name and virtual address stay, and remain the only address used by ordinary request traffic from other services. 2. The per-instance names exist alongside them and are used *only* by the narrow path that justified them. 3. The justification is written down where the service is declared, so a reviewer a year later can see it was a decision rather than a habit. Without point three, direct addressing spreads by copy-paste. Somebody's template that legitimately needed per-instance names becomes the starting point for a service that did not, and the estate accumulates callers holding member lists with no idea why. | | virtual address for everything | direct addressing for the narrow case | |---|---|---| | who tracks membership | the platform | the caller | | who spreads load | the platform | the caller | | replica churn is | invisible | visible and must be handled | | worth it when | the caller needs any member | the caller needs one named member | ## The failure mode to watch for afterwards The estate-level symptom of granting this too freely is uniform and slow: several callers that each hold their own idea of who exists, disagreeing during every rollout. One holds a member that is gone, another has not noticed a member that arrived, and errors cluster around deploys of a service whose own logs look healthy. Because each caller solved it differently, there is no single place to fix it — which is the strongest practical argument for keeping the indirection the platform owns as the default, and treating every exception as something a team must justify and then maintain. A final note on register: this is a standard you set, not a mechanism you recite. The good answer names the narrow legitimate cases, states what the caller inherits, and says how you stop the exception becoming the norm.