Short on time? Start with a well-structured modular monolith unless you have clear reasons for microservices: many teams that need independent releases, very different scaling needs for parts of the system or strict isolation requirements. Split services later, once real boundaries are known.
Few technical choices attract stronger opinions than how to structure a web application. Some teams swear by microservices, others call them over-engineering. For a business leader paying for the build, the question is practical: which approach delivers working software sooner, costs less to run and stays easy to change?
This guide compares three shapes, the monolith, the modular monolith and microservices. It explains when each fits, what they cost in time and people, and how to move between them. It applies to a startup building its first product and to an enterprise redesigning a core platform.
Key takeaways
- A monolith is one deployable application. It is simple to build, test and run, and can grow hard to change if it has no internal structure.
- A modular monolith keeps one deployment but enforces clear internal modules. It keeps most benefits of a monolith and prepares for splitting later.
- Microservices are many small services that deploy independently. They suit large organisations and uneven scaling needs, and they bring operational complexity.
- Team size, release needs and skills should drive the choice, not fashion.
- Moving in steps is safer than a full rewrite.
The three shapes
Monolith
All features live in one codebase and run as one unit, usually with one database. A request flows through the same process from interface to data.
Strengths: simple development, easy debugging, fast calls between parts, one deployment, low infrastructure cost, straightforward transactions.
Weaknesses: without discipline, code becomes tangled, so a change in one area breaks another. Releases touch everything, so all teams must coordinate. Scaling means scaling the whole application. Long build and test times can slow large teams.
Modular monolith
Still one deployment and often one database, but the code is divided into modules with clear responsibilities and defined interfaces between them. Modules cannot reach into each other’s internals. Tools and tests enforce the boundaries.
Strengths: keeps simplicity of operations while giving the clarity and independence of modules. Teams can own modules. Splitting a module into a service later is easier.
Weaknesses: needs discipline and tooling to keep boundaries. One deployment unit still means a shared release cycle.
Microservices
The application is a set of small services, each owning a business capability and its data, communicating through APIs or messages. Each service deploys independently.
Strengths: independent releases and scaling, technology freedom per service, fault isolation, alignment with autonomous teams.
Weaknesses: distributed systems are harder. You need service discovery, monitoring, tracing, deployment automation, API versioning and strategies for data consistency. Network calls add latency and failure modes. Testing across services is more difficult. Operating costs and skill needs rise.
What experts say
Software author Martin Fowler argues in his piece on starting with a monolith that teams should usually begin new projects as a monolith, because early speed and feedback matter and stable service boundaries are hard to see at the start. A monolith lets teams learn where boundaries belong before splitting. He notes that the opposing view has some merit and that the evidence is limited, so treat this as a strong rule of thumb, and think through your own context.
A decision guide
Ask these questions:
- How many developers and teams? A single team of up to roughly a dozen people rarely needs microservices. Many teams that block each other on releases may.
- How well do we understand the domain? If boundaries are unclear, splitting early produces the wrong services.
- Do parts of the system have very different scaling or reliability needs? A heavy image processing function might deserve its own service.
- Do we need independent release cycles? Regulated or customer-specific modules sometimes do.
- What operations skills and tooling do we have? Microservices need mature automation and monitoring.
- What is the time to market? Simpler structures reach users sooner.
- What is the budget? More services mean more infrastructure and more people.
- Are there security or compliance reasons to isolate components?
Hybrid and staged approaches
- Modular monolith first, extract later. Start with modules and carve out a service when a clear need appears, such as a scaling hotspot or a team that needs autonomy.
- Strangler pattern for legacy systems. Place a routing layer in front of an old application and move functions to new services one by one. Our article on legacy application modernization describes this approach.
- Serverless functions for event-driven or bursty tasks, alongside a core application.
- Separate front end and back end with an API between them, so interface and logic can evolve independently.
Data matters most
Boundaries around data decide whether a split works. Each service should own its data and expose it through an interface. Shared databases create hidden coupling. Distributed transactions are hard, so design for eventual consistency where possible and use patterns such as sagas and outbox for workflows across services.
Operating considerations
- Deployment: automate builds, tests and releases. Containers and orchestrators help at scale. Our Kubernetes article explains when that is justified.
- Observability: centralised logs, metrics and traces across components.
- Resilience: timeouts, retries, circuit breakers and graceful degradation.
- Security: authentication between services, least privilege and secret management.
- Testing: unit, integration and contract tests, plus end-to-end checks for key journeys.
Signs you chose wrongly
- A monolith: builds take very long, teams wait for each other, a small change needs a full regression and nobody dares touch certain code.
- Microservices: many tiny services with constant cross-service changes, release coordination across a dozen services, debugging takes days and the cloud bill rises with little benefit.
When you see these signs, adjust gradually. Merge services that always change together, or add structure to a tangled monolith.
Cost view
Monolith and modular monolith usually cost less to build and operate for small and medium products. Microservices bring higher platform and staffing costs that pay back at scale. Ask for estimates that include infrastructure, tooling, monitoring and people, over three years.
Common mistakes
- Choosing microservices for a product with three developers.
- Building a monolith with no internal boundaries.
- Splitting by technical layer instead of business capability.
- Sharing one database among many services.
- Starting a full rewrite when targeted refactoring would do.
How SoftSapien helps with architecture
SoftSapien designs and builds web applications and platforms across these patterns, and helps teams evolve legacy systems in safe steps. Explore our web application development and enterprise software engineering services.
For an architecture review, visit the contact page to chat with our team, send a message or schedule a free consultation call.
Frequently asked questions
What is a modular monolith?
It is one deployable application whose code is divided into modules with clear responsibilities and enforced interfaces, which keeps operations simple and prepares for splitting later.
When do microservices make sense?
When many teams need independent releases, parts of the system scale very differently or strict isolation is required, and you have the automation and monitoring skills to run them.
Should a startup begin with microservices?
Usually no. A well-structured monolith reaches users sooner, and service boundaries are easier to find once the product and domain are understood.
How do I move from a monolith to services?
Extract one module at a time when a clear need appears, route traffic through a gateway and keep each service owning its own data.
Can SoftSapien review our architecture?
Yes, with practical recommendations. Contact SoftSapien through the contact page to chat with our team, send a message or schedule a free consultation call.
