Microservices offer several attractive benefits: independent deployments, flexible scaling, better team autonomy, and the ability to evolve different parts of an application separately. But these benefits come at a cost.

Microservices introduce network communication, distributed data management, service coordination, monitoring, and additional infrastructure. This raises an important architectural question:

When does adopting microservices actually make sense?

Choosing microservices simply because an application needs to scale is rarely a convincing reason. A strong engineer understands the problems microservices solve, recognizes when those problems are significant enough, and knows when a simpler architecture would be more effective.

In this chapter, we'll explore the situations where microservices provide real value, the warning signs that suggest you should avoid them, and a practical framework for making architectural decisions.

Imagine you're building a new food delivery application. The product needs restaurant listings, user accounts, order placement, payments, and delivery tracking. You could immediately create separate microservices for each capability. But should you?

If you're working with a team of five engineers, the application has a few hundred users, and the product requirements are changing every week, microservices might introduce more problems than they solve. Your team would need to maintain multiple services, deployment pipelines, API contracts, and distributed communication infrastructure. A modular monolith could deliver the same functionality with significantly less operational complexity.

Now imagine the application has grown. Millions of customers use it, restaurant discovery receives far more traffic than payment processing, and separate engineering teams manage orders, payments, and delivery logistics. Deployments are increasingly difficult because changes from different teams interfere with each other.

In this situation, microservices become much more attractive. The business requirements haven't fundamentally changed. Customers still browse restaurants and place orders. What changed is the scale of the organization, the operational requirements, and the need for independent evolution.

Let's examine the most common situations where microservices provide meaningful benefits.

Multiple Teams Need Independent Ownership

One of the strongest reasons to adopt microservices is organizational complexity. Imagine an e-commerce platform with 15 engineering teams working on a single monolithic application.

The catalog team wants to release search improvements. The payments team needs to update its payment provider integration. The order management team is introducing a new checkout workflow. If these changes share the same deployment pipeline, database schemas, and tightly coupled modules, coordination can become expensive.

Microservices allow teams to own specific business capabilities. The Catalog Service can evolve independently of the Payment Service, provided their contracts remain compatible. Teams can develop, test, and deploy changes without waiting for a centralized release. This can significantly improve development velocity.

However, creating microservices doesn't automatically eliminate dependencies. If every service change requires updates across several other services, the organization still has a coordination problem. The service boundaries must support genuinely independent work.

Different Components Have Different Scaling Requirements

Consider a video streaming platform. The video catalog receives large numbers of browsing requests, recommendations require computationally expensive processing, and subscription billing handles comparatively fewer transactions. These workloads have different resource requirements.

In a monolith, scaling the application often means adding instances containing all its functionality. Microservices allow individual components to scale independently. For example, the Recommendation Service might require more CPU resources, while the Catalog Service benefits from additional application instances and caching. This can improve infrastructure efficiency.

However, it's important to distinguish between high traffic and independent scaling requirements. The stronger argument is that different parts of the application have substantially different scaling characteristics.

Services Need Independent Deployment Cycles

Some business capabilities change much more frequently than others. Imagine an online marketplace.

The recommendation team experiments with new ranking algorithms daily. Meanwhile, the payments team follows strict testing, security, and release procedures. If both capabilities belong to one deployment unit, their release schedules may interfere.

With microservices, each team can follow an appropriate deployment process. The recommendation team can release frequently without forcing payment-related code through the same deployment. This independence becomes especially useful when different components have different risk profiles.

Business Domains Have Clear Boundaries

Microservices work best when an application contains well-understood business domains. For example, a mature e-commerce platform might have distinct capabilities for catalog management, order processing, payments, and fulfillment. Each domain has its own business rules, data, and lifecycle. These boundaries make it easier to identify service responsibilities and ownership.

However, if the business requirements are constantly changing, service boundaries may be difficult to define. Separating unstable domains too early can lead to frequent cross-service changes and expensive refactoring. A good microservices architecture depends on understanding where the boundaries should be.

Fault Isolation Is Important

Microservices can also help isolate failures. Imagine a platform where recommendations are temporarily unavailable. Ideally, customers should still be able to browse products and complete purchases. Separating recommendations into an independently operated service makes it easier to allocate resources and apply failure isolation policies.

But this benefit isn't automatic. If checkout synchronously depends on recommendations, a recommendation outage could still affect purchases. Microservices provide opportunities for fault isolation, but resilience requires appropriate dependency management, timeouts, circuit breakers, and graceful degradation.

Here is the same recommendation outage under two different dependency designs:

Now let's look at situations where microservices are often the wrong choice.

You're Building an MVP or Early-Stage Product

Early-stage products usually have uncertain requirements. Business rules change frequently, features are added or removed, and the team is still discovering what customers actually need. Introducing microservices too early can make every architectural change more expensive.

For example, functionality initially placed in separate services might later turn out to belong in one business domain. Moving logic and data between services can require API changes, database migrations, and coordination across deployments. A modular monolith provides greater flexibility while the domain model is still evolving. You can establish clean module boundaries without committing to a distributed architecture.

Your Engineering Team Is Small

Imagine four engineers maintaining 20 microservices. Each service may need monitoring, configuration, deployment automation, dependency updates, and incident handling. Even if the services are individually simple, their combined operational overhead can become significant. A small team may spend more time maintaining infrastructure than building product features.

Microservices become more attractive when independent teams can own and operate meaningful business capabilities. But there's no universal rule that a particular team size requires microservices. The important question is whether the organization can manage the operational responsibilities effectively.

Your Application Is Tightly Coupled

Some applications involve business operations that frequently access and update closely related data. If every user request needs synchronous calls across several services, splitting the application may increase latency and failure risks.

Consider a system where pricing, discounts, inventory, and order validation rely heavily on shared business rules and transactional state. Separating them without clear boundaries could create complicated distributed workflows. Keeping closely related functionality together may be more practical. Microservices should reduce unnecessary coupling, not turn ordinary function calls into complicated network interactions.

You Need Simple Transaction Management

Suppose an application frequently performs operations requiring atomic changes across several related entities. Within a monolith using one transactional database, these updates may be handled through a single database transaction.

With microservices and independently owned databases, those operations require additional coordination. You might need Saga workflows, compensating transactions, idempotency, and eventual consistency. These patterns are useful, but they increase complexity. If distributed transactions provide no meaningful business benefit, introducing them unnecessarily is difficult to justify.

Your Team Lacks Operational Maturity

Microservices require more than application development skills. Teams need reliable CI/CD pipelines, centralized logging, distributed tracing, metrics, alerting, configuration management, and incident response processes. They must understand how to troubleshoot failures across multiple services. Without these capabilities, operating microservices can become difficult.

This doesn't mean every organization needs Kubernetes or a sophisticated service mesh before adopting microservices. Managed infrastructure and simple deployment approaches can be sufficient. But the team must be prepared to handle distributed systems failures and operational responsibilities.

The architectural decision doesn't have to be all-or-nothing. A modular monolith provides a useful middle ground. It keeps the application in one deployable unit while organizing functionality into clearly defined business modules.

For example, an e-commerce application could have separate Catalog, Order, Payment, and Inventory modules. Each module exposes internal interfaces and encapsulates its business logic. The modules communicate through in-process calls rather than network requests. This provides several advantages:

A modular monolith isn't a temporary or inferior architecture. It can remain an effective long-term solution. The key is to preserve meaningful boundaries instead of allowing every module to directly access every other module's internal implementation.

Here is the e-commerce example as a modular monolith, with module boundaries inside a single deployable unit:

Migrating to microservices should usually be driven by concrete problems rather than anticipated future scale. Some useful warning signs include:

Deployment bottlenecks: Teams regularly delay releases because unrelated changes must be coordinated.

Scaling inefficiency: Specific components require significantly more resources, but the entire application must scale together.

Ownership conflicts: Different teams frequently modify the same code and struggle to maintain clear responsibilities.

Reliability concerns: Failures in one component repeatedly affect unrelated business capabilities.

Development friction: The codebase has become difficult to change because business boundaries are poorly enforced.

However, these symptoms don't automatically require microservices.

That investigation can follow a simple path before any service gets extracted:

If microservices are justified, avoid migrating the entire application at once. A gradual approach reduces risk and allows the team to learn.

One commonly used technique is the Strangler Fig pattern. The idea is to extract selected capabilities from the existing application while keeping the rest of the monolith operational. For example:

The first service should ideally have a clear responsibility and relatively few dependencies. Payments or order processing may be poor initial candidates if they require complicated distributed transactions. Over time, the organization can move toward a hybrid architecture or a more complete microservices model.

Importantly, you don't need to extract every module. Some functionality may remain in the monolith indefinitely. The goal is to improve the architecture, not maximize the number of services.

You can evaluate whether to adopt microservices using five questions.

If most answers favor independence, microservices deserve consideration. If most answers favor simplicity, a modular monolith is often a better choice.

This isn't a mechanical scoring system. A single strong constraint, such as a strict isolation requirement, may justify extracting a particular capability. The purpose is to make the reasoning explicit.

Microservices are valuable when an application needs independent deployment, scaling, ownership, or failure isolation across meaningful business capabilities. But they introduce significant complexity in communication, data consistency, infrastructure, testing, and operations.

For small teams, early-stage products, and tightly connected business workflows, a modular monolith is often the simpler and more effective choice. As the application and organization grow, specific capabilities can be extracted when the benefits justify the cost. The most important principle is:

Don't adopt microservices because your application might become complex someday. Adopt them when they solve problems that are already meaningful or clearly supported by your requirements.

Be clear about the problems you're solving, the alternatives you've considered, and the trade-offs you're willing to accept. That's what strong architectural judgment looks like.