Decision memo: remove competing service routes by choosing one authoritative path and making the fallback prove its limits.
The service appeared to work, which was part of the problem. Two routes could reach substantially the same behavior. They had accumulated for understandable reasons, and ordinary use did not make the overlap obvious. Yet the paths did not carry identical authentication and freshness guarantees. Depending on how a request arrived, one route could bypass the expected protection or serve behavior that lagged behind the path everyone believed was current.
Calling this “routing debt” would've described the code while letting me avoid the uncomfortable part. I still had to decide which path owned the service.
Decision
Choose one authoritative route for normal traffic. It owns the current authentication boundary, delivered behavior, and operational evidence. References, configuration, and dependent callers move toward that route.
The other route becomes a protected fallback with a narrow, documented purpose. It doesn't remain a peer in case somebody prefers it later. Where it can't enforce the required authentication and freshness behavior, it must reject the request or remain unavailable. A fallback that silently offers weaker semantics is an alternate production system, not resilience.
This decision is intentionally stronger than cleaning up duplicate configuration. If both routes remain valid in principle, the next implementation will preserve both branches and the ambiguity will return under better names.
Documentation, health checks, and support guidance will refer to the authoritative path first. The fallback will be named only in recovery material that also states its restrictions. This prevents ordinary operational habit from restoring peer status after the code changes.
Alternatives
One option was to keep both routes and make them equivalent. That sounds cautious, but it creates two enforcement points to test and monitor. Every future authentication change, cache rule, and service behavior would need proof through both. Equivalence would be a continuing obligation, not a one-time patch.
Another option was to place a selector in front and route according to circumstance. That would centralize the branch without resolving it. Operators would still need to know which behavior each path supplied, and failures in the selector could expose the weaker route at exactly the wrong time.
A third option was immediate removal of the fallback. The simplicity was attractive, but removal before caller and recovery evidence was complete would trade ambiguity for an avoidable outage risk. Protecting and constraining the fallback allows the migration to proceed without pretending it remains an equal path.
The rejected alternatives are recorded because duplicate routes often return through institutional amnesia. Without the reasoning, a future maintainer can mistake reintroducing the second active route for harmless redundancy.
Owner
One service owner is accountable for the authoritative route and the fallback policy. Network configuration, application behavior, and authentication may involve different maintainers, but the decision can't be split into three partial ownership claims.
That owner maintains the caller inventory, approves migration exceptions, and decides whether the fallback remains necessary. They also own the user-visible semantics: a request through the supported endpoint receives current behavior under the expected protection. Infrastructure health alone can't close this work.
Changes touching either route require that owner's review until the fallback expires. This is temporary coordination, but it closes the gap in which separate maintainers can each make a locally reasonable change and recreate divergent behavior.
Exceptions need names and dates. “A legacy consumer may still use it” isn't an owner. The consumer, responsible person, reason, and required migration evidence belong in the memo. If nobody can identify the dependency, uncertainty should prompt observation, not permanent preservation.
Expiry
The fallback designation expires at the next formal review after caller migration and a recovery exercise. At expiry, the owner must either remove the route or renew its narrow purpose with current evidence.
Renewal isn't automatic. It must state which supported recovery condition requires the fallback, how authentication remains enforced, how freshness is guaranteed, and when the question will return. If those conditions can't be demonstrated, the route is disabled.
The expiry also applies to compatibility rules introduced during migration. Redirects, aliases, and temporary configuration can become a third path if left unowned. Each receives the same deadline and a named removal condition.
Proof
Proof begins with route identity. Requests to the supported endpoint must be traceable to the authoritative handler, and the old path must not remain reachable through an overlooked configuration branch. Static inspection helps, but delivered-route checks are required.
Authentication tests cover both paths. The authoritative route accepts correctly authorized requests and rejects unauthorized ones. The protected fallback rejects traffic outside its narrow allowed condition; it can't bypass the main control simply because it reaches the same backend another way.
Negative tests matter most here. A request lacking the required identity, a request using the retired address, and a request attempting the fallback outside its recovery condition must all produce the documented rejection. Success-path tests alone would preserve the original blind spot.
Freshness tests then demonstrate that the authoritative route serves current behavior after a change. The fallback, while it exists, must either serve the same proven behavior or fail closed. A stale but responsive route doesn't pass.
Finally, the caller inventory and operational evidence are reviewed together. Known consumers use the authoritative endpoint. Logs and configuration show no unexplained use of the fallback during the observation period. The recovery exercise confirms that a documented failure doesn't automatically expose the weaker path.
I won't close the memo while two routes can quietly claim the same job. It closes when normal traffic uses the chosen path, the fallback rejects anything outside its narrow condition, and its owner either removes it at expiry or writes down why it gets another date. If that decision feels blunt, good. The ambiguity was already doing sharper damage.