How do you break a Go import cycle that the compiler rejects between two packages?

## The rule If package `a` imports `b` and `b` imports `a`, the build fails: import cycle not allowed and the toolchain prints the full chain, which matters because real cycles are usually indirect: `a` imports `b`, `b` imports `c`, `c` imports `a`. A package also cannot import itself. There is no flag, no forward declaration and no lazy-resolution mode. One clarification that trips people up: **the rule is between packages, never between files**. Two files in the same package may reference each other's declarations freely, in any order, with no imports involved. Splitting code into more files is free; splitting it into more packages is what creates edges. ## Why Go insists on a DAG Two parts of the model depend on it. First, **compilation**: Go compiles a package once, as a unit, into a single object file, and it needs its dependencies already compiled to do so. A cycle has no valid compilation order. This is a large part of why Go builds are fast — there is never a fixed-point iteration or a partial-type dance. Second, **initialisation**: package-level variables and initialisation functions run in dependency order, each imported package fully initialised before the package that imports it. A cycle has no valid order there either, and languages that permit cycles pay for it with half-initialised modules that behave differently depending on which file was loaded first. So the restriction is not pedantry; it buys a build model and an initialisation model with no undefined corners. ## Break one: the interface on the consumer's side This is the move that is specific to Go and the one an interviewer wants to hear. Go interfaces are satisfied **implicitly**. A type implements an interface by having the right methods; it never declares that it does, and it never imports the package where the interface lives. So an interface can be declared by whichever package *needs* the behaviour rather than by the package that *provides* it. Suppose `order` wants to send a notification and therefore imports `mail`, while `mail` needs an order's fields and therefore imports `order`. Instead, `order` declares a one-method interface describing what it needs, takes it as a parameter, and imports nothing new. `mail` supplies a type with that method and never mentions `order`. The edge from `mail` to `order` is gone, and the cycle with it — with no change to how either package is used at the call site that wires them together, typically the main package. The cost is a small amount of indirection. Keep the interface tiny and define it where it is consumed, which is idiomatic Go regardless of cycles. ## Break two: extract a third package When the cycle exists because both sides need the same **types** — a domain entity, an identifier, an error value — move those types into a third package that imports neither side. Both packages import it, and the edge between them disappears. This works cleanly when the extracted package is genuinely a leaf with no dependencies of its own. It fails, or merely relocates the cycle, when people use it as a dumping ground for anything two packages happen to share: such a package accumulates dependencies, eventually needs to import one of its own consumers, and the cycle returns in a less obvious form. ## Break three: move the code Often the cycle is a straightforward misplacement. A function sits in the package that does not own the data it manipulates, so it has to import the one that does, while that one already imports it for something else. Moving the function to the side that owns the data removes an edge and usually reads better afterwards. ## Break four: merge If two packages cannot be described without each other — every change to one changes the other, and their types are mutually recursive — the honest conclusion is that they are one package that was split too early. Merging them is not a defeat; Go packages are meant to be units of *meaning* rather than units of file organisation, and a cycle is a strong signal that a boundary was drawn where there is no seam. ## Reading the cycle as a design signal Before choosing a technique, ask which direction the dependency *should* run. Usually one of the two packages is more general or more stable, and it should not know about the other at all. The cycle appeared because a specific concern leaked into the general package. The interface break formalises that answer; extraction and merging are the other two shapes it can take. What to avoid is adding an interface purely to placate the compiler, without deciding which side is the consumer. That leaves indirection every future reader must trace with no design gained.