Monolith vs. Microservices: Understanding their architecture
How two architectures differ and how they can be used for software engineers.
Introduction
Neither architecture is better in general: a monolith buys simplicity, microservices buy independence, and each charges for what the other gives away. The right choice depends on the size of the system, the size of the team, its operational maturity and how fast the product is changing.
The choice is one of the earliest and most expensive decisions in a software project. It shapes how code is organised, how teams are split, how releases happen and how the system scales. Getting it wrong in either direction is costly: a monolith that outgrows its team slows every release, while microservices adopted too early bury a small team in infrastructure work.
Netflix is the classic example of the shift. In 2009 its infrastructure could not keep up with streaming demand, so it moved from its own data centres to the public cloud and broke its monolith into services, before the word "microservices" was in common use. It now runs more than a thousand services and deploys many times a day (Atlassian ). Yet GitHub, Shopify and Instagram all grew for years on monoliths (Arslan Ahmad ). Both paths can succeed; what matters is knowing why.
What is a monolithic architecture?
A monolith is one application, built from one codebase and shipped as one deployable unit. Every business capability (user accounts, authentication, billing, search, notifications) lives in the same codebase and runs in the same process.
A typical monolith has three layers that ship together:
- Client-side UI – what the user sees and interacts with.
- Server-side application – the business logic, using the server's CPU, memory and storage.
- Database – usually one shared relational database.
Modules talk to each other through ordinary function calls, and a change anywhere means rebuilding and redeploying the whole application. This is the traditional model, with roots in the mainframe era, and it is still widely and successfully used today (IBM ).
What is a microservices architecture?
Microservices split an application into small, independent services, each owning one business capability and usually its own data. Services talk to each other over the network through well-defined APIs or events, and each one can be built, tested, deployed and scaled on its own (AWS ).
A large platform might have separate services for accounts, payments, search, recommendations and notifications, each owned by a different team. Services are usually packaged in containers and run on cloud infrastructure, and the style goes hand in hand with DevOps and continuous delivery.
One point all four references agree on: microservices do not remove complexity, they move it. The tangled dependencies inside a monolith become explicit network boundaries between services. That makes complexity easier to see and to divide among teams, but it adds a new class of distributed-systems problems.
Monolith: advantages and disadvantages
A monolith is fastest and cheapest while the system and team are small; its costs grow with the codebase and the headcount.
Advantages
- Fast to start. Little up-front design is needed. One codebase, one build, one pipeline, so a small team spends its time on features rather than infrastructure.
- Simple deployment. One artifact goes to one environment; there is no service discovery, API versioning or orchestration to manage.
- Easy debugging and testing. A request can be traced from the API to the database in one process, with one set of logs. End-to-end tests run against a single unit.
- Performance. In-process function calls are far cheaper than network calls, and there is no serialisation overhead between components.
- Simple data consistency. One database means one transaction can keep related data correct.
- Smaller attack surface. Fewer exposed endpoints between components to secure.
Disadvantages
- Slows down as it grows. In a large codebase, dependencies become hard to understand, and a change in one module can break an unrelated one.
- All-or-nothing deployment. A one-line fix needs the whole application rebuilt, retested and redeployed, so releases become slower and riskier.
- Coarse scaling. You must scale the whole application even if only one feature is under load, wasting resources. AWS's example: a traffic spike in one communication feature forces you to add capacity for everything.
- Single point of failure. A memory leak or crash in one module can take down the entire application for every user.
- Locked-in technology. Changing the language, framework or a major library touches the whole system, so upgrades are expensive and often postponed.
- Team friction. Many developers in one repository means more merge conflicts and more coordination for each release.
Microservices: advantages and disadvantages
Microservices pay off when many teams and uneven workloads must move independently; below that threshold their overhead usually outweighs the gains.
Advantages
- Independent deployment. Each service ships on its own schedule. After moving to microservices, Atlassian went from releasing about once a week to two or three times a day (Atlassian ).
- Fine-grained scaling. Add capacity only to the service under load, such as video processing, rather than to the whole system.
- Fault isolation. A well-designed system keeps one failing service from taking everything down, reducing the blast radius of bugs and bad deploys.
- Team autonomy and clear ownership. Service boundaries become team boundaries: the payments team owns payments, the search team owns search. Large organisations scale more easily this way.
- Technology freedom. Each service can use the language, framework or database that best fits its job.
- Easier change in a large system. Developers work in a small codebase and only need to know other services' APIs, not their internals.
Disadvantages
- Distributed-systems problems. Function calls become network calls that can time out, fail, retry, duplicate or arrive out of order. Partial failures, where one service succeeds and another fails, need careful handling.
- Harder debugging. One user request may cross ten services, each with its own logs. You need centralised logging, distributed tracing and metrics just to see what happened.
- Data consistency. With a database per service, one transaction can no longer keep everything correct. Teams fall back on events, eventual consistency and compensating actions.
- Operational and infrastructure cost. Every service needs its own pipeline, hosting, monitoring and tests. Containers, orchestration and a platform team become prerequisites.
- Latency and security exposure. Network hops add delay, and every API and gateway is another surface to authenticate and protect (IBM ).
- Sprawl. Without shared standards, services multiply with inconsistent languages, logging and ownership. Atlassian grew from about 15 services in 2016 to more than 1,300 and had to build an internal service catalogue to keep track.
When to use each
Start with a well-structured monolith, and split out services only when a concrete problem demands it. Copying Netflix's or Uber's architecture on day one solves problems a small team does not have yet.
Choose a monolith when
- The team is small (a handful of engineers) and works closely together.
- You are building an MVP, prototype or early-stage product whose requirements change weekly.
- The domain is simple or its boundaries are not yet clear.
- Operational resources and DevOps experience are limited.
- Traffic is moderate and roughly even across features.
Choose microservices when
- Several teams need to ship independently and coordinating releases has become a bottleneck.
- Parts of the system have very different load or scaling needs.
- Some components need stronger isolation or availability than others.
- The domain is large, well understood and has clear boundaries.
- You already have the platform: containers, CI/CD, monitoring, tracing and people who can run them.
Conclusion
Choose the simplest architecture that solves today's problem and leaves room for tomorrow's. For most new products that is a well-structured, modular monolith. Microservices earn their cost once team size, deployment friction or uneven scaling make independence worth more than simplicity. Let real constraints drive the decision, not industry trends.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article