An interface seam in your Go library's hot path costs an allocation per call, but other teams substitute fakes through it. How do you decide whether to remove it?

## The decision, not the technique The technical facts are usually settled quickly: an interface call cannot be inlined, arguments passed through it are assumed to escape, and boxing a value into it may allocate. What makes this a judgment call is that the seam is not a mistake — someone put it there so other teams could substitute an implementation, and they did. Removing it converts your performance problem into their work. ## Step one: size the prize on the real workload A microbenchmark comparing a concrete call to an interface call will show a large relative difference and almost no absolute one. The number that decides anything is the share of the *service's* time and allocation rate attributable to this call site under a representative load. Two allocations per request on a service that already allocates a thousand is noise. Two allocations per pixel row is a different conversation. Get the profile before writing the change, not after. ## Step two: exhaust the changes that cost no one anything Ranked by how little they cost other people: 1. **Keep the exported interface; move the loop underneath it.** The seam stays exactly where consumers see it, and the per-iteration work moves into an unexported function over the concrete type. Nobody outside the package can tell, and most of the win is usually here. 2. **Stop the per-call allocation from the other side.** Let the caller own and reuse the buffer, or pool it, so the loop stops manufacturing values to box. Again invisible outside. 3. **Let a profile-guided build devirtualise the hot site.** No API change at all, contingent on the profile staying representative. Treat it as a real option, and as one whose input ages. If these get you the number you need, you are done and no cross-team conversation is required. This is the outcome to aim for. ## Step three: if the API must change, price it honestly Removing an interface from a published surface has costs that do not show in your profile: - **Migration work multiplied by consumers.** Every team with a fake behind that interface has to replace it. You are spending their sprint capacity, so it is your job to count the consumers before proposing it, not after. - **Testability.** If you take the seam away, you owe them something else — a genuine lightweight implementation shipped in the package, an exported test helper, or a narrower interface at a different level where the cost is once-per-request instead of once-per-item. - **Reversibility.** Adding an interface back later is easy; retracting a concrete type you exposed is not. Prefer the change you can undo. - **Whose budget.** In a repository where the library and its consumers ship together, this is a same-change edit. Across teams and release trains it is a migration with a window, an announcement and a deadline, and it should be planned as one. ## Step four: make the decision inspectable Write down, in the package or the design note, what you measured, on what workload, which alternatives you rejected and why, and what would change the answer. Two reasons. The reviewer who thinks the seam is worth the allocation should be arguing with a number, and the person who arrives in a year to ask why this package has an odd concrete signature should find the answer without re-running your profile. Then guard it. A benchmark in the package that asserts allocations per operation is what stops the next well-intentioned refactor from putting the interface back in the loop. ## The failure modes to name - **Optimising the API for a benchmark.** The change wins in the microbenchmark and moves nothing in production. - **A blanket rule.** *No interfaces on hot paths* is not a policy; it is a way of losing seams nobody measured. - **Silent removal.** Deleting a seam consumers depend on and finding out in their build. If they cannot be told, they cannot plan. - **Never deciding.** The mirror image: a seam that measurably costs a fifth of the service's CPU and stays because changing it would require a conversation. Owning the call includes being willing to make the expensive one.