Advantages and Disadvantages of Microservices Architecture
The advantages and disadvantages of microservices architecture come from one decision: splitting an application into small, independently deployable services that talk over the network. You gain independent deployment, scaling and failure isolation. You pay for it with network calls, harder data consistency and much more to operate.
This tutorial explains how microservices work, walks through each advantage and disadvantage, compares microservices with a monolith, and covers the mistakes teams make most often. It ends with interview questions for your preparation.
1. What Is Microservices Architecture?
A monolith is one application, built and deployed as a single unit. All features, such as orders, payments and inventory, run in the same process and usually share one database.
Microservices architecture splits those features into separate services. Each service owns one business capability, has its own database, runs as its own process, and can be released without touching the others. If the basics are new to you, start with the introduction to microservices.
2. How Microservices Architecture Works
In a monolith, the order code calls the payment code with an ordinary Java method call. It takes nanoseconds and never gets lost. In microservices, the same step becomes a remote call. The request is turned into JSON or another format, sent over the network, handled by another process, and sent back. Each of those steps can be slow or fail.
Clients usually enter through an API gateway, and services also exchange events through a message broker. Every advantage and every disadvantage below comes from replacing method calls with network calls.
3. Advantages of Microservices Architecture
3.1 Independent Deployment
A team can release a fix to the Payment Service on Tuesday without redeploying the whole shop. Smaller releases are easier to test, faster to roll back and less risky.
3.2 Independent Scaling
During a sale, search traffic may grow ten times while account settings stay quiet. With microservices you add instances of the busy service only, instead of copying the entire application, which saves money.
3.3 Failure Isolation
Each service runs in its own process. A memory leak or crash in the recommendation feature cannot take down checkout's process, as long as callers handle the failure, for example with a fallback or a circuit breaker.
3.4 Technology Freedom
Each service can use the tools that fit it, such as a different database or a newer Java version, without changing the others.
3.5 Team Autonomy
Small teams can own a service end to end: code, database and releases. They coordinate through APIs instead of shared code, which helps large organisations move faster.
4. Disadvantages of Microservices Architecture
4.1 Network Latency and Partial Failure
Every remote call adds latency and a new way to fail: timeouts, dropped connections, a service that is restarting. Code must expect that some calls fail while others succeed, which is called partial failure.
4.2 Lower Availability for Long Call Chains
This is the cost most tutorials skip. If one request needs five services to answer one after another, it succeeds only when all five are up. The availabilities multiply, so the chain is less available than any single service. Five services at 99.9% each give only about 99.5% for the whole request: roughly 216 minutes of downtime a month instead of 43.
4.3 Data Consistency
With a database per service, one database transaction can no longer cover an order and its payment. If the second step fails, nothing rolls back the first. You need patterns such as the Saga pattern, and you must accept that data is consistent eventually, not instantly. For example, an order can be saved while its payment fails, leaving it marked as created although nobody paid.
4.4 Operational Overhead
Ten services mean ten pipelines, ten sets of logs and metrics, and versioned APIs between them. You usually need centralised logging, distributed tracing, service discovery and container orchestration before the system is manageable.
4.5 Harder Testing and Debugging
A bug may appear only when three services interact, and reproducing it needs all of them and their data.
5. Monolith vs Microservices: Comparison
| Aspect | Monolith | Microservices |
|---|---|---|
| Deployment | Whole application at once | Each service on its own |
| Scaling | Copy the whole application | Scale only busy services |
| Calls between features | In-process method calls | Network calls that can fail |
| Data | One database, ACID transactions | Database per service, eventual consistency |
| Failure impact | A crash can stop everything | Contained, if callers handle failures |
| Operations | Simple: one app to run and monitor | Complex: tracing, discovery, orchestration |
| Best for | Small teams, new products, unclear domains | Large teams, well-understood domains, uneven load |
The monolithic vs microservices comparison covers the two styles in more depth.
6. Common Mistakes When Adopting Microservices
- The distributed monolith: services that must be deployed together, or that call each other for every request. You get all the costs and none of the benefits.
- A shared database: two services writing the same tables are coupled through the schema, so neither can change it alone.
- Services that are too small: splitting by class or table instead of business capability creates chatty services and long call chains.
- Starting too early: splitting before the domain is understood puts boundaries in the wrong places.
- No observability: without correlated logs and tracing, finding which service failed becomes guesswork.
7. Best Practices
- Start with a well-structured monolith and extract services when a clear need appears.
- Draw boundaries around business capabilities, using Domain-Driven Design.
- Give every service its own database and share data through APIs or events.
- Keep synchronous call chains short, and prefer events where an immediate answer is not needed.
- Add timeouts, retries and fallbacks to every remote call.
- Invest in observability early: logs, metrics and distributed tracing.
8. Summary
- Microservices replace in-process method calls with network calls between independently deployable services.
- The main advantages are independent deployment, independent scaling, failure isolation, technology freedom and team autonomy.
- The main disadvantages are latency and partial failure, lower availability for long call chains, harder data consistency, and higher operational and testing cost.
- Availability multiplies along synchronous chains, and there is no shared rollback across services.
- Weigh the advantages and disadvantages of microservices architecture against your team size and domain; for many projects, a modular monolith is the right first step.
Microservices Advantages and Disadvantages: Interview Questions
Common interview questions on the trade-offs of microservices, from basic to scenario-based, with short answers.
Basic questions
Q. When should you not choose microservices?
Answer: Avoid them for small teams, new products whose domain is still changing, and systems without uneven load or independent release needs. In those cases the operational cost outweighs the benefits, and a well-structured monolith is faster to build and easier to run.
Q. What is a modular monolith, and why is it often a good first step?
Answer: A modular monolith is a single deployable application whose code is split into strict modules, for example one Java package or Maven module per business capability, with clear interfaces between them. You keep simple deployment and local transactions, and if a module later needs to scale or release on its own, its boundaries are already in place to extract it as a service.
Q. Why is a shared database considered an anti-pattern in microservices?
Answer: If two services read and write the same tables, a schema change for one can break the other, so they can no longer be deployed independently. Each service should own its data and expose it only through an API or events, which is the database per service pattern.
Intermediate questions
Q. What is a distributed monolith, and how do you recognise one?
Answer: A distributed monolith is a system split into services that still behave like one application. Typical signs: services must be released together, one user request triggers long chains of synchronous calls, services share a database, or a change to one service's API forces changes in many others. It has the network costs of microservices without their independence.
Q. How do you keep data consistent across services without distributed transactions?
Answer: Use eventual consistency: each service commits its own local transaction and publishes an event, and other services react to it. A Saga coordinates multi-step processes and runs compensating actions when a step fails. To avoid losing events, the transactional outbox pattern writes the event to an outbox table in the same local transaction as the data change, and a separate process publishes it.
Q. How do you debug a request that passes through many services?
Answer: Give every request a trace ID at the edge and pass it on every call, so logs from all services can be joined. Distributed tracing tools such as OpenTelemetry, or Micrometer Tracing in Spring Boot, record each hop and its duration. Centralised logging then lets you search all services for one trace ID.
Q. How does microservices architecture change testing?
Answer: Unit tests stay the same, but integration across services becomes harder to test end to end. Teams add contract tests, often consumer-driven, so a provider cannot break the API its consumers expect, and keep a small number of end-to-end tests for critical flows.
Q. How big should a microservice be?
Answer: Size it by business capability, not by lines of code. A good service covers one bounded context, can be owned by one team, and rarely needs to change together with another service. If two services always change and deploy together, they probably belong together.
Q. How does Conway's law relate to microservices?
Answer: Conway's law says a system's structure tends to mirror the communication structure of the organisation that builds it. Microservices work best when service boundaries match team boundaries, so each team can own and release its services without constant coordination.
Tricky and scenario questions
Q. After splitting a monolith, checkout became slower. What are the likely causes and fixes?
Answer: Former method calls are now network calls, each adding serialisation and network time, and a loop that called another module per item may now make one HTTP request per item. Fix it by batching calls, adding a bulk endpoint, caching stable data, calling independent services in parallel, and moving non-urgent steps such as notifications to asynchronous events.
Q. How would you migrate a large monolith to microservices safely?
Answer: Use the strangler fig approach: put a gateway or routing layer in front of the monolith, extract one capability at a time into a new service, and route its traffic to the service while everything else still goes to the monolith. Start with a capability that has clear boundaries and real benefit from independence, and move its data last, once the new service is stable.
Q. Are microservices more secure than a monolith?
Answer: Not automatically. There are more network endpoints to protect, and service-to-service traffic must be authenticated too, for example with tokens or mutual TLS. The benefit is containment: a compromised service with narrow permissions and its own database exposes less than a compromised monolith with access to everything.
Q. Can microservices share code through a common library?
Answer: Yes, for technical concerns such as logging, security filters or HTTP client configuration. Sharing domain models is risky, because changing a shared Order class forces every service using it to upgrade and redeploy together. Keep shared libraries small, versioned and free of business logic.