Monolithic or modular architecture for growing web systems

When should a growing web system remain monolithic and when should it become modular?

A growing web system should remain monolithic as long as changes can be delivered together and internal module boundaries sufficiently limit coupling. Standalone modules or services are worthwhile when change cycles differ, data ownership is clear, and operational isolation is necessary. Decomposition follows observed coupling, not a pre-selected architectural style.

Diagnostic Case: "Premature Extraction"

The catalog, shopping cart, and editorial content reside within a single application but are separated by clear internal interfaces. Extraction is only considered when the catalog needs to scale independently and be frequently published by a separate team. The shopping cart remains in the monolith because separation would currently only generate distributed transactions.

Premature Extraction

• Premature Extraction A still-changing business boundary is fixed as a network contract, slowing down learning.

• Distributed Monolith Separate deployments remain coupled via synchronous calls and shared data, requiring coordination of each release.

• Operational Multiplication – Each new entity requires its own telemetry, access control, and recovery, without providing corresponding benefits.

Controlled Data Sovereignty

1. Evaluate change history and identify areas that are frequently modified together or repeatedly independently.

2. Stabilize the strongest candidate boundary internally via interfaces and separate tests within the monolith.

3. Extract a unit only if its benefits are proven, and then re-measure coupling, release flow, and operational effort.

Independent change cycle

• Independent change cycle – The candidate is regularly modified independently and demonstrably slowed down by shared releases.

• Controlled Data Sovereignty – The module can maintain its data and consistency rules without forcing continuous distributed write operations.

• Operating costs borne – Deployment, monitoring, security, and fault diagnosis of the additional unit are covered by personnel and technology.

Operating costs borne

What to consider when discussing "Monolithic or Modular Web Architecture"

Maintaining a robust decision file for digital systems answers the next practical question: What information belongs in a robust decision-making document for digital systems?

Making performance budgets binding for new features continues this line of thought with another question: How do performance budgets for new website features become truly binding?

If you want to practically implement "Monolithic or Modular Web Architecture," you can refer to Robust Website Systems which focuses on "Architectural Boundaries and Scaling" and "Independent Change Cycle."

Conclusion: Monolith or Modular Web Architecture

A structured monolith is a viable architecture as long as its boundaries effectively manage changes. Distribution is a targeted response to demonstrated independence and not a maturity indicator.

Sources and Further Information

The primary sources define the technical framework for "monolith or modular web architecture."

• OpenAPI SpecificationPrimary specification for machine-readable HTTP API contracts, including operations, data models, and error responses.

• Choosing Technology: An Introduction – GOV.UK Service ManualOfficial guidance on prototyping integrations, carefully cutting components, and evolving via open standards.

• 14. Operate a reliable service – GOV.UK Service ManualOfficial standard for the operation, availability, recovery, and continuous improvement of reliable services.