What is a modular monolith and how does it differ from a traditional monolith?

A modular monolith is a single-deployment application divided into well-bounded modules — each module has its own domain, its own database tables (or PostgreSQL schema), and a clear API surface that other modules must use to access its data. A traditional monolith (Big Ball of Mud) has no architectural boundaries — all code can access all data directly. The key difference: a modular monolith is easy to extract into microservices later (each module becomes a service) because the boundaries already exist. A Big Ball of Mud is very hard to decompose because the code is tangled. ClickMasters builds modular monoliths with explicit module boundaries as the foundation for future microservices migration.

When should a UK project migrate from modular monolith to microservices?

Migrate from modular monolith to microservices when: (1) team grows beyond 15–20 engineers and independent deployment cadence is genuinely needed (different modules deploy at different rates), (2) FCA PS21/3 IBS resilience genuinely requires independent failure domains (IBSs must be isolated from each other), (3) a specific module needs to scale independently at 10× the rate of the rest of the application. Do not migrate when: team is under 15 engineers, you believe it will "improve code quality" (it will not — it adds complexity), or you are following a trend. ClickMasters has migrated 8 modular monoliths to microservices — all migrations happened post-Series B, not before.

Monolith Vs Microservices Vs Modular Monolith

Monolith vs Microservices vs Modular Monolith — UK Architecture (2025)

Updated: November 20259 min read

🇬🇧 UK💷 GBP📊 Comparison🔒 UK GDPR⚖️ UK Law

Direct Answer

Modular monolith is the right default for most UK projects: faster to build than microservices, as maintainable as microservices when modules are well-bounded, and operationally simpler. Full microservices are right for large teams (20+ engineers) with genuine independent deployment requirements. Traditional unmodular monolith (Big Ball of Mud) is wrong — not because it is a monolith but because it has no architectural boundaries. The UK project mistake is going to microservices too early, not too late. Architecture choice is one of the highest-stakes technical decisions. Here is an honest 2025 UK assessment — based on real project experience across regulated UK sectors.

Factor	Big Ball of Mud	Modular Monolith	Microservices
Team size	Any (starts fine, degrades)	✅ 1–20 engineers	20+ engineers
Build speed	✅ Fastest initially	✅ Fast — only one deployment	Slower — service overhead
UK GDPR data isolation	Hard to enforce (all data accessible)	✅ Module boundaries enforce access	✅ Database-per-service (strongest)
FCA PS21/3 IBS resilience	Single deployment — all IBSs fail together	✅ Module isolation + retry logic	✅ IBS-per-service independent failure
Operational complexity	✅ Simple — one deployment	✅ Simple — one deployment	High — service mesh, distributed tracing
Cyber Essentials patching	✅ One container to patch	✅ One container to patch	Multiple containers to patch per service
Independent deployment	No (all code deploys together)	No (all code deploys together)	✅ Yes — per service
Refactoring to microservices later	Hard — no existing boundaries	✅ Easy — extract module as service	Already microservices
ClickMasters default	Never (for regulated UK software)	✅ All UK projects (< Series B)	Post-Series B + 20+ engineers