As a Go tech lead, would you require every service package to export an interface so consumers can mock it?

## What is actually being decided The question is not "are interfaces good". It is whether the *producer* of a type owes every consumer a pre-declared abstraction. In Go that is a genuine choice, because the language does not force it: satisfaction is structural and checked at the point of use, so any package can create the abstraction it needs, whenever it needs it, without the producer's cooperation. The mandate therefore buys convenience and consistency, not capability -- and it is a decision a tech lead owns and an API reviewer can overrule, which is why it is worth deciding deliberately rather than by habit. ## The case for the mandate, stated fairly The strongest advocate is usually the engineer who owns test infrastructure. Their argument is real: - **Uniformity.** If every service package exports `Fooer`, doubles can be produced the same way everywhere and nobody has to think. - **Onboarding.** Engineers arriving from ecosystems where interfaces are declared up front find the codebase familiar. - **A visible seam.** The interface documents, in one place, what a service does. - **No arguments in review.** A mechanical rule ends a recurring debate, and ending recurring debates has value on its own. Dismissing this as cargo-culting is the wrong move. It is a bid for lower variance, and variance genuinely costs teams. ## The costs, which compound quietly - **A second permanent surface.** Every package now exports an interface plus a concrete type. Importers name the interface in their own signatures and struct fields, so it is load-bearing whether or not it earns its keep. - **It cannot be widened.** Adding a method to an interface that outside code implements breaks that code at compile time; adding a method to a struct breaks nobody. The mandate converts a safe change into an unsafe one in every package it touches. - **The abstraction is the wrong shape.** A mirror of one struct abstracts nothing, and the fourteen-method version gives every stand-in fourteen behaviours to get wrong. Drift then produces the worst failure mode there is: a fully green suite over a broken integration. - **Callers lose the type.** Constructors that return the interface hide fields, hide later methods and degrade the documentation consumers read. - **It is unremovable at scale.** Once dozens of packages export interfaces and hundreds of call sites name them, walking it back is a large mechanical change nobody schedules. ## The policy I would set **Default:** return concrete types; declare interfaces where they are consumed, as narrow as the consumer's actual use, and unexported when only that package needs the name. **Written exceptions, so the default is not litigated weekly:** 1. Two or more implementations ship in the same release. 2. The interface is the contract another team implements -- a plugin point, an extension seam. 3. The dependency is outside the process and outside your control (a vendor API, a payments backend), where the seam has to exist regardless. 4. A constructor genuinely returns different concrete types depending on its input. **Owner and appeal path:** the owning team decides inside its package; anything exported goes past API review, and the lead breaks ties. Say out loud that the reviewer may overrule the author here, because an exported interface is a promise the whole organisation keeps. **Make it observable.** Count exported interfaces with exactly one implementation in the repository and watch the number over time. A policy with no measurement is a preference. **Give the advocate a real answer, not a veto.** If their pain is that doubles are inconsistent, solve that: put the stand-in and one exported behaviour suite next to the real implementation, so consumers get a supported fake without every package exporting an interface. That satisfies the uniformity argument without the coupling. ## What it costs to change your mind later If the organisation is pre-production or single-repo, removal is a mechanical change: delete the interface, return the concrete type, fix call sites, one commit. If external consumers already import the interface, removal is a breaking release, and the honest options are to keep the interface as a published contract you promise never to widen, or to version the module. That asymmetry is the reason to make the default choice early: adopting an interface later is free in Go, and removing one later is not.