Monolith vs Microservices UK — The Honest Decision Framework (2025)

Conway's Law (1967) states: "Any organisation that designs a system will produce a design whose structure is a copy of the organisation's communication structure." In software: if you have one team, you will naturally build a monolith. If you have five teams, you will naturally build five services. This is not a coincidence — it reflects how coordination costs work. Microservices are most valuable when they allow different teams to work independently without coordination overhead. If your team is so small that everyone talks to everyone else anyway, microservices add complexity without reducing coordination costs.

Q: When is it too early for microservices?

A: It is too early for microservices when: your team has fewer than 8 engineers, your codebase is less than 2 years old, your deployment frequency is once a week or less, you don't have multiple teams who need to deploy independently, and your system does not have specific services requiring dramatically different scaling. Most UK startups that adopt microservices prematurely spend 18 months untangling the complexity they created and either revert to a monolith or hire expensive distributed systems engineers to manage it.

Q: What is a modular monolith?

A: A modular monolith (sometimes called a "structured monolith") is a single-deployable application with clear internal boundaries between modules. Each module: has a well-defined API (even if internal), owns its data (no other module directly accesses its database tables), and can be reasoned about independently. A good modular monolith is much easier to decompose into microservices later than a "big ball of mud" monolith — and is easier to operate than microservices now.

Q: How do you migrate from monolith to microservices safely?

A: The safest approach is the strangler fig pattern: incrementally extract services at the edges of the monolith while the monolith continues to function. Start with: the service with the most independent deployment requirements, the service with the clearest bounded context (from Domain-Driven Design), and the service that genuinely needs different scaling. Do not attempt to decompose the entire monolith at once — this "big bang" migration has an extremely poor success rate.