Most Go codebases begin as straightforward layered monoliths, but years of growth often turn those layers into a web of hidden coupling, unclear ownership, and hard-to-predict side effects. Small changes start requiring deep context, and compile and test times slowly creep up, turning routine work into risky work. Rewrites promise a clean slate but rarely succeed in practice. What the Go community lacks are real examples of large open source Go projects that have successfully evolved toward a modular monolith.

This talk presents a major open source Go project in the middle of that evolution. It covers how we are moving from a decade-old layered architecture toward a modular design while continuing to ship features to multiple production environments that teams actively depend on every day. This is not theory. This is architectural change in a live system, with real contributors, long CI pipelines, social constraints, and legacy assumptions embedded throughout the code.

What began as an investigation into slow build and test times exposed deeper problems: oversized packages, uncontrolled dependencies, unclear boundaries, and an architecture that no longer matched how engineers actually reasoned about the system. We walk through familiar pain points in large Go monoliths, including tight coupling, long feedback cycles, and frequent merge conflicts, and explain why these problems persist even in well-intentioned codebases. You’ll see where our early attempts stalled, how architectural changes regressed quietly over time, why good ideas alone were not enough, and how steady, incremental refactoring helped us regain control without freezing development. Architecture only works when people agree to carry it together.

Whether you are working on a fast-growing Go project or maintaining a mature production system, this talk will give you concrete techniques and mental models for evolving your architecture safely. You’ll leave with a clearer understanding of how to introduce boundaries that hold, align ownership with code, and make a large system feel smaller, safer, and easier to change, so teams can move faster without needing to hold the entire system in their heads.