For a platform with 30+ engineers and a domain that is still not well understood, what makes a modular monolith the wrong default choice, and what long-term organizational failure mode most often erodes a modular monolith's boundaries even after they were enforced correctly at launch?

## Two situations where it is the wrong default There are two genuinely distinct situations where a modular monolith is the wrong default, and they're worth separating because they call for different alternatives. ## The first: the domain is not yet understood The first is when the domain is not yet understood: a brand-new product, a company entering a market it has never operated in, or a team still discovering what the real seams of the business even are. - Any module boundary drawn under those conditions is a guess, and the guess is often wrong, because the natural decomposition of a domain usually only becomes clear after real usage and iteration reveal where change actually clusters. - Redrawing a wrong boundary inside a monolith is cheaper than redrawing it across separately deployed microservices, but it still isn't free: other code has already been written against the wrong module's public API and DTOs, and migrating those callers, deprecating the old interface, and moving entities between modules' internal packages is real, deliberate work. In this situation, many teams deliberately choose to start with a single, undivided codebase — sometimes called 'monolith first' — and defer imposing enforced boundaries until usage patterns make the real seams obvious, rather than paying repeatedly to redraw premature ones. ## The second: different needs from day one The second situation is when parts of the system have fundamentally different non-functional needs from the outset — not eventually, but from day one. A part of the system that needs to scale independently by orders of magnitude, that has a genuine compliance requirement for physical or network-level isolation such as a payment-card-scope boundary, or that is a much better fit for a different runtime or language, is not well served by a modular monolith no matter how cleanly its module is bounded in code, because the shared-process constraint — everyone in the same JVM, everyone scaling and deploying together — is itself the mismatch. A code-level boundary, however well enforced, cannot give one module its own scaling profile or its own separately audited network perimeter; that requires an actual process and deployment boundary, which is what a microservice or a genuinely separate deployable provides. ## The slow failure: boundary erosion through exemption creep Even when neither of those conditions applies at launch, and the modular monolith is initially the right call with genuinely well-enforced boundaries, a slower and more insidious failure mode tends to erode it over years: boundary erosion through exemption creep. Unlike a microservice's network boundary, which is physically inescapable — you literally cannot call another service's private in-memory state without going over the wire — a modular monolith's boundary is a policy enforced entirely by tooling running inside one process, and policy can be weakened from the inside. A critical production bug needs a fix in twenty minutes, and the 'correct' fix of adding a new API method and waiting for review and deploy is slower than importing the internal class directly and suppressing the check just this once with a documented TODO. Multiply that by dozens of engineers over several years, and each individual exemption is defensible on its own, but the aggregate quietly reintroduces exactly the everything-can-reach-everything coupling the enforcement was built to prevent. ## How the erosion shows up How this shows up in practice is telling: - Reviewers stop treating a boundary-tool failure as automatically blocking because there are already 'too many exceptions to bother'. - A new engineer can't tell from the code which dependencies are load-bearing architecture and which are legacy escape hatches nobody ever cleaned up. - When the team finally attempts a real service extraction years later, they discover the boundary is far leakier than the passing CI check implied, because the exceptions were granted once and never revisited. ## The ongoing tax, not the one-time setup Teams that have publicly discussed maintaining large modular monoliths over many years, including well-known cases of Ruby-on-Rails codebases adopting boundary-enforcement tooling at scale, describe this as an ongoing tax, not a one-time setup. It requires: - periodic audits of the exception list; - a policy that every suppression or allowed-dependency entry carries an owner and either an expiry date or a linked ticket rather than being permanent; - treating the trend in the number of exemptions — not just whether the verification test currently passes — as a first-class health metric the team actively tries to shrink, not merely tolerate.