Monolith vs Microservices
Two Ways to Structure an Application
Monolith vs microservices describes two ways to structure an application. A monolith is built and deployed as a single unit. Its features, such as user accounts, product catalogue, orders and payments, live in one codebase and usually share one database. Microservices split the application into small services, each responsible for one business capability. They run separately and communicate over the network, often through HTTP APIs or message queues.
Neither approach is inherently better. A monolith is simpler to build, test and run, while microservices allow parts of the system to be deployed and scaled independently, at the cost of more operational complexity.
Trade-offs in Practice
- Deployment: a monolith is released as one package. Microservices can be released independently, which helps large teams but requires coordinating many components.
- Scaling: a monolith scales as a whole. Microservices let a heavy component, such as image processing, scale on its own.
- Complexity: a monolith keeps calls inside one process. Microservices add network failures, service discovery, monitoring across services and data consistency between databases.
- Team structure: small teams often move faster with one codebase. Microservices suit organisations where separate teams own separate services.
- Failure isolation: a fault in one microservice can often be contained, while a serious fault in a monolith can affect the whole application.
Operational cost is often the deciding factor. Each extra service needs its own deployment, monitoring, logs and on-call responsibility, so a team without automation for these may struggle. Teams usually adopt microservices when specific problems, such as independent scaling or separate release cycles, are clear and measurable.
Choosing the Right Structure for a Store
A small online store with one team, a single database and modest traffic is usually well served by a monolith. Deployments are simple, often a single pipeline run, and the team can change features without coordinating across services. If the store later adds video processing with very different resource needs, that component could be split out as its own service while the rest stays together.
Many successful systems began as monoliths and were split later. A common middle ground is the modular monolith, described in the questions below.
Frequently asked questions
Are Microservices Always Better Than a Monolith?
No. Microservices solve problems of scale and organisation that many projects do not have. Introducing them early adds network communication, deployment pipelines and monitoring work that can slow a small team down. The architecture should follow from the project's size, team and requirements.
What Is a Modular Monolith?
A modular monolith is a single deployable application organised into modules with clear boundaries, each owning its own logic and data. It keeps the simple deployment of a monolith while preparing the code for a later move to separate services, if one is needed. For how code is organised inside an application, see MVC architecture.
How Does Hosting Differ for a Monolith and Microservices?
A monolith typically runs as one application process behind a web server, connected to one database. Microservices run as several services, often in containers, and need networking between them, service discovery, logs from each service and a way to deploy and restart them independently. Single-application hosting plans are rarely enough for a microservice setup.