16.3 — Investigate spoke-to-spoke shortcut plans

[vrabbi]

Phase: Phase 16 — Engine and strategy expansion
Proposal: docs/proposals/next-phases.md §16
Priority: P3 · Size: M

---

Problem

Router.Convert always routes spoke A → hub → spoke B: two Convert calls, never a direct path. This keeps compilation cost linear in the number of spokes (O(N) plans rather than O(N²)) and is a deliberate, documented choice.

Phase 9 measured the cost: for a 1000-element forEach object, spoke-to-spoke is ~2.3x a single hop and still under 1 ms.

Goal

Decide, with evidence, whether this is worth changing — and record the answer either way.

Non-goals

Building it speculatively. This issue is an investigation, and closing it with "no, and here is why" is a complete and successful outcome.

Design

1. Find out whether it matters. Spoke-to-spoke conversion only occurs when a client reads at version B an object stored at hub, having been written at A — or in practice, whenever a controller and a user prefer different non-hub versions. Instrument the direction labels already on dco_webhook_conversion_objects_total to find out how often real deployments do spoke-to-spoke at all. If it is rare, the answer is no and the issue closes.
2. If it is common, quantify at realistic object sizes rather than the 1000-element worst case, and against the apiserver's own overhead — a 2.3x multiplier on 300 µs is invisible next to admission and etcd latency.
3. Only then consider a design: lazily compiled direct plans, cached per observed pair, so cost is paid only for pairs that actually occur — which preserves the O(N) property for the common case.

The most likely and most useful outcome is a documented "no": a measured statement in docs/operations/capacity.md that spoke-to-spoke is 2.3x a single hop, that this is inherent to the hub-and-spoke design, and that it is not worth optimising — so the question stops being re-asked.

Acceptance criteria

• Real-world spoke-to-spoke frequency measured or reasoned about from the existing metrics
• A recommendation with numbers behind it
• docs/limitations.md and docs/operations/capacity.md updated with the conclusion
• If the answer is "no": the issue closes with the reasoning recorded, and the design seam stays documented for anyone who revisits it

---

Generated by Claude Code