Monolith Isn’t the Problem—It’s the Big Ball of Mud

Monolith vs. Big Ball of Mud

IBM defines a monolith as a single code repository that implements multiple business functions. The definition does not require the code to be tangled. A "big ball of mud" is any system—monolith or microservice—where code lacks explicit module boundaries. The key distinction is the presence of clear module boundaries, not the number of repositories.

Monolith is not the problem; the lack of module boundaries is.

MonolithFirst – Martin Fowler (2015)

Fowler’s MonolithFirst article proposes starting with a monolith and only splitting when the monolith becomes a genuine problem. The reasoning chain is:

If you cannot clearly define module boundaries inside the monolith, breaking it into microservices will only spread the confusion.

Practice modularization within the monolith before considering any split.

YAGNI applies at the architectural level: do not split for a hypothetical future need for independent deployment.

Splitting without clear boundaries merely moves chaos from code to the network.

Architecture Spectrum (Youngju Kim 2026)

Kim’s Platform Architecture Decision Guide models architecture as a spectrum rather than a binary choice:

Monolith – single process, no explicit module boundaries, whole‑application deployment.

Modular Monolith – single process, explicit module APIs, still whole‑application deployment.

Macroservices – few processes, modules have boundaries and can be deployed per module.

Microservices – many processes, each service has its own deployment unit.

Teams locate themselves on this continuum based on size, deployment needs, and business complexity.

Modular Monolith Design Principles (Kamil Grzybek)

Grzybek’s "Modular Monolith with DDD" outlines four concrete rules:

Single‑process execution: All modules run in the same process, eliminating network overhead and giving latency‑sensitive applications a natural advantage.

Maximum module autonomy: Each module owns its domain model and its own database schema or tables, preventing hidden cross‑module data access.

DDD bounded contexts: Module boundaries align with bounded contexts, ensuring consistent meaning within a context and avoiding name clashes across contexts.

Explicit module API: Modules communicate only through public APIs, keeping internal implementations private.

Modular monoliths have microservice‑like boundaries, but they exist in code rather than in deployment.

Regression Cases

Amazon Prime Video (2023): The video‑quality analysis system was migrated from a distributed microservice architecture back to a monolith. Cost dropped by more than 90 %. The team concluded that independent deployment was unnecessary; Step Functions orchestration added network latency and coordination overhead that far exceeded the actual computation.

Appsmith (InfoQ 2024): For teams under 150 engineers, the operational burden of service discovery, monitoring, distributed tracing, and CI/CD pipelines outweighed any benefits, so a monolith was chosen to keep development efficient.

Basecamp / Shopify (early years): Both operated at massive scale—millions of users and billions in transactions—using monolithic architectures, demonstrating that a well‑modularized monolith can scale far beyond typical expectations.

Monolith Advantages & Disadvantages

Advantages: Single codebase, IDE support, one‑click deployment, easy debugging (single process), fast intra‑process calls, smaller attack surface.

Disadvantages: A single deployment touches all features (higher change risk), limited independent scaling, technology‑stack lock‑in, and lack of module‑level extensibility.

Whether the disadvantages matter depends on context; a small team may accept them in exchange for simplicity.

Three Common Misconceptions

Misconception: "Monolith = big ball of mud". Correct view: A monolith can have clear module boundaries; a big ball of mud is boundary‑less code regardless of repository layout. ( Kamil Grzybek; Fowler MonolithFirst )

Misconception: "Monolith cannot scale". Correct view: Basecamp and Shopify show monoliths can support massive scale; scaling is achieved by adding machines, not by splitting modules. ( DHH; Shopify engineering blog )

Misconception: "Monolith is obsolete". Correct view: Fowler’s MonolithFirst, Amazon Prime Video’s 2023 regression, and Appsmith’s 2024 choice demonstrate continued relevance. ( Fowler MonolithFirst; Amazon Prime Video 2023; Appsmith/InfoQ 2024 )

Takeaway

The decisive factor is not whether an architecture is monolithic, but whether clear module boundaries exist. Start with a modular monolith, prove that boundaries are well defined, and only then consider splitting into services. Architecture decisions should be based on concrete trade‑offs, not on fashion.