Monolith vs Microservices vs Modular Monolith: Which Architecture Should Your Application Use?

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Monolith versus microservices is the architecture decision most likely to be made for the wrong reasons. This guide explains what each means, adds the modular monolith that most teams should actually choose, compares them on speed of development, scaling, reliability, cost, team structure and operations, and gives a rule for when to split a system into services.

Definitions

Monolith

One application, one codebase, one deployment, usually one database. All features run in the same process and call each other directly. Simple to build, test, deploy and debug; harder to scale selectively and to keep tidy as it grows without discipline.

Modular monolith

A monolith organized into modules with explicit boundaries and interfaces (for example, orders, billing, accounts), enforced by code structure and tooling, still deployed as one unit. It keeps the operational simplicity of a monolith while making later extraction of services possible.

Microservices

Many small, independently deployable services, each owning its data and communicating over the network (HTTP, gRPC, messaging). Each service can scale, deploy and fail on its own and can use its own technology. The cost is distributed-systems complexity: network failures, data consistency, service discovery, observability and many pipelines.

Why microservices are tempting and often wrong

Microservices were popularized by companies operating at enormous scale with hundreds of engineers. The benefits are real at that scale; the costs are real at every scale. A five-person team running twelve services spends its time on infrastructure instead of product, and a distributed monolith (services that must deploy together) is worse than either extreme. Amazon’s own Prime Video team published a case in 2023 of consolidating a microservice pipeline into a monolith to cut cost (Prime Video Tech blog), which is a useful reminder that the arrow points both ways. Martin Fowler’s MonolithFirst essay makes the same case.

When microservices are the right call

• Parts of the system have very different load profiles (a search or media-processing component that must scale independently).
• Separate teams own separate business domains and need to deploy without coordinating.
• Reliability requirements demand that one component failing does not take down the rest.
• Different components genuinely need different runtimes (for example, a Python machine-learning service beside a Node API).
• The organization already has platform engineering, CI/CD, observability and on-call practices.

When a monolith (modular) is the right call

• One team, or a few, building one product.
• Requirements are still changing and boundaries are not yet clear.
• Load is modest or uniform.
• Operations capacity is limited.
• Speed of delivery matters more than independent scaling.

How to build a monolith that can split later

1. Organize code by business domain, not by technical layer.
2. Give each module a public interface and forbid reaching into another module’s internals.
3. Keep module data in module-owned tables and avoid cross-module joins in application code.
4. Use events or explicit calls between modules so that dependencies are visible.
5. Automate boundary checks in CI.
6. Extract a service only when a specific module needs independent scaling, deployment or ownership.

Cost and operations comparison

Serverless and other options

Serverless functions can implement either style: a monolith deployed as a few functions, or services as many. Event-driven architectures and the modular monolith are not exclusive; most modern SaaS products are modular monoliths with a few extracted services (search, media, notifications) and queues between them. See backend development services and SaaS hosting.

How Progression Agency architects applications

We build modular monoliths by default, in Next.js and Node or Django, with queues for background work and clean module boundaries, and we extract services only when a documented need appears. Architecture decisions are written down with the reasons. See custom software development, API development and choosing a tech stack.

Frequently asked questions