Free lesson · Microservices Interview

When to Adopt Microservices (And When to Stay Monolithic)

Easy10 min readmicroservicessystem-designdistributed-systems

When to Adopt Microservices (And When to Stay Monolithic)

The previous lesson laid out the tradeoffs. This lesson turns those tradeoffs into a decision framework - a repeatable process for evaluating whether a system should use microservices, remain a monolith, or land somewhere in between.

This is directly interview-applicable. When an interviewer gives you a system design problem, the first architectural decision you make - before drawing a single box - is whether microservices are appropriate. This lesson gives you the reasoning structure to make that decision quickly and defend it under questioning.

The Decision Framework

The framework has five evaluation criteria. They are ordered by importance - the first criterion alone eliminates microservices for a large class of systems.

graph TD
    Start["Should I use\nmicroservices?"] --> Q1{"Team size\n> 30 engineers?"}
    Q1 -->|"No"| Mono1["Strong monolith\ncandidate"]
    Q1 -->|"Yes"| Q2{"Can you identify\nclear bounded\ncontexts?"}
    Q2 -->|"No"| Mono2["Stay monolith until\ndomain is clearer"]
    Q2 -->|"Yes"| Q3{"Do components have\ndifferent scaling or\navailability needs?"}
    Q3 -->|"No"| Mono3["Consider modular\nmonolith"]
    Q3 -->|"Yes"| Q4{"Can you invest in\ninfrastructure and\noperational tooling?"}
    Q4 -->|"No"| Mono4["Microservices without\ninfrastructure = pain"]
    Q4 -->|"Yes"| Q5{"Do teams need\nindependent deployment\ncycles?"}
    Q5 -->|"No"| Mono5["Modular monolith\nmay suffice"]
    Q5 -->|"Yes"| Micro["Microservices\nare appropriate"]

This diagram shows a decision tree for choosing microservices versus monolith. It starts with team size - if under 30 engineers, lean toward monolith. Then it asks about clear bounded contexts, different scaling needs, infrastructure investment capacity, and independent deployment requirements. Only when all five criteria are met does the framework recommend microservices.

Let me walk through each criterion.

Criterion 1 - Team Size and Organisational Scale

The question: How many engineers are working on this system, and is the monolith creating coordination bottlenecks?

This is the most important criterion because microservices are fundamentally an organisational scaling strategy. If you have a small team that can coordinate effectively around a single codebase, microservices add complexity without adding value.

The threshold is not precise - it depends on the team's discipline, the codebase structure, and the deployment pipeline - but as a practical guide:

• Under 15 engineers: Almost never need microservices. A well-structured monolith is faster to develop, easier to debug, and simpler to operate.
• 15–50 engineers: The grey zone. Coordination friction is appearing but can often be managed with a modular monolith, feature branches, and a fast CI/CD pipeline. Evaluate the other criteria before committing to microservices.
• Over 50 engineers: Microservices are likely necessary. The coordination overhead of a monolith at this scale - merge conflicts, deployment queues, test suite contention, release coordination - typically exceeds the overhead of distributed system complexity.

At Amazon, the transition happened when teams could no longer ship independently within the monolith. The two-pizza team structure was the organisational response, and microservices were the technical implementation of that organisational choice.

Interview: In interviews, the system scale usually implies the team scale. "Design a food delivery platform serving 10 million users" implies a large engineering organisation. "Design an internal tool for a 20-person company" implies a small team. Let the scale of the problem guide your architecture choice, and state your reasoning: "At this scale, I would expect multiple teams working on different parts of the system, so microservices make sense for independent development and deployment."

Criterion 2 - Domain Clarity

The question: Do you understand the domain well enough to draw service boundaries confidently?

This criterion is where experienced engineers separate from inexperienced ones. Drawing microservices boundaries requires knowing where the seams in the domain are - which concepts belong together, which can be separated, where the coupling is low enough that a network boundary will not create constant back-and-forth communication.

If the domain is new, unclear, or rapidly evolving - as it is in most startups - you do not have enough information to draw good boundaries. Decomposing prematurely locks you into boundaries that are expensive to move later. A service boundary is a deployment boundary, a data boundary, and a team boundary. Moving it means migrating data, changing APIs, and reorganising teams.

The practical rule: if you cannot name the bounded contexts in your domain and describe the relationships between them, you are not ready for microservices. Build a monolith, learn the domain through production experience, and decompose when the boundaries become clear through use.

Module 02 covers domain-driven design and boundary identification in depth. The tools it teaches - bounded contexts, context mapping, aggregate identification - are the tools for evaluating this criterion.

Criterion 3 - Differential Requirements

The question: Do different parts of the system have meaningfully different scaling, availability, consistency, or technology requirements?

If every part of the system has similar characteristics - similar load patterns, similar consistency needs, similar availability targets - a monolith serves them equally well. Microservices add value when different components have different operational requirements.

For example, in a food delivery platform:

• The order placement flow needs strong consistency and moderate throughput - you cannot accept an order you cannot fulfil
• The restaurant search needs high read throughput and can tolerate slightly stale data - showing a restaurant that closed 30 seconds ago is acceptable
• The delivery tracking needs real-time event processing and high write throughput - location updates arrive every few seconds from thousands of drivers
• The analytics dashboard needs batch processing and can tolerate minutes of latency

These four components have genuinely different scaling, consistency, and processing requirements. Separating them into services allows each to use the technology and scaling strategy that fits its specific needs. The search service can use Elasticsearch. The order service can use PostgreSQL. The tracking service can use a time-series database. None of them is forced into a one-size-fits-all technology choice.

If all components had similar requirements - similar load, similar consistency needs, similar technology - the argument for separation weakens. A monolith could serve them with a single database and a single scaling strategy.

This criterion is also where candidates demonstrate depth in interviews. Naming the specific requirements that differ - not just "they have different needs" but "the search component needs 50x the read throughput of the admin panel and can tolerate 30-second staleness, while the payment component needs strong consistency and handles 100x fewer transactions" - shows the interviewer you are reasoning about concrete system characteristics rather than applying a generic rule.

Tip: When proposing microservices in an interview, name at least two components with concretely different requirements. "The real-time tracking service processes 10,000 location updates per second and needs a time-series data model, while the order service handles 500 transactions per second and needs ACID guarantees. These different data models and throughput patterns argue for separate services." This specificity is what separates a strong decomposition rationale from a hand-wavy one.

Criterion 4 - Infrastructure and Operational Capacity

The question: Does your organisation have (or can it build) the infrastructure and operational capability to run a distributed system?

Microservices require operational infrastructure that monoliths do not. At a minimum:

• Service discovery - how services find each other
• Distributed tracing - how you follow a request across services
• Centralised logging - how you aggregate and correlate logs from multiple services
• CI/CD per service - how each service builds and deploys independently
• Health monitoring and alerting - how you know when a service is unhealthy
• Container orchestration - how you manage service deployment, scaling, and networking

At Netflix, the platform engineering team that provides this infrastructure is a significant engineering investment in itself. At Amazon, the internal tooling for service management is one of the company's most valuable assets. These capabilities do not come for free.

A team that adopts microservices without this infrastructure will spend more time fighting operational problems - service discovery failures, deployment pipeline issues, debugging across services without tracing - than building features. The operational overhead can easily consume 30-40 percent of engineering capacity in the first year.

Warning: "We will build the infrastructure later" is one of the most common microservices adoption failures. Teams start building services, discover they cannot debug production issues because they have no distributed tracing, scramble to add observability after the fact, and spend six months catching up on infrastructure they should have built first. If you cannot invest in the operational foundation before building services on top of it, stay with a monolith until you can.

Criterion 5 - Independent Deployment Needs

The question: Do different parts of the system genuinely need to deploy on different schedules?

This is the final criterion because it tests whether you need the defining property of microservices. If all components deploy together on the same schedule - because they are maintained by the same team, or because the deployment process is fast enough that coordination is not painful - the primary benefit of microservices (independent deployability) is not doing work.

Independent deployment becomes necessary when:

• Different teams own different components and need to ship on their own timelines
• Some components change frequently (user-facing features) while others change rarely (billing infrastructure)
• Regulatory requirements mandate that certain components (payment processing, data handling) go through separate approval processes
• The deployment pipeline for the full system is so slow that teams are blocked waiting for their changes to reach production

If none of these apply - if deployment is fast and coordination is light - a modular monolith with a single deployment pipeline can deliver the same velocity with less complexity.

The "You Are Not Netflix" Conversation

I need to address this directly because it comes up in every microservices discussion, and it should come up in your interviews too.

Netflix runs one of the most sophisticated microservices architectures in the world. Their engineering blog posts describe resilience patterns, chaos engineering, real-time streaming, and infrastructure automation at a scale that most companies will never approach. Those blog posts are valuable learning material.

They are also a terrible basis for your architecture decisions.

Netflix has over 2,000 engineers. They stream video to 250 million subscribers across 190 countries. Their operational infrastructure team is itself larger than most companies' entire engineering departments. The architecture decisions they make are correct for Netflix, at Netflix's scale, with Netflix's resources.

When a 30-person startup adopts Kafka, a service mesh, distributed tracing, and 40 microservices because "Netflix does it," they are solving problems they do not have with tools they cannot afford to operate. The result is not a mini-Netflix. The result is a team that spends 60 percent of its time on infrastructure and 40 percent on the product.

The same is true for Amazon, Google, Uber, and every other company whose architecture is cited as a microservices success story. Their architecture is a response to their scale. Your architecture should be a response to your scale.

Interview: Referencing Netflix or Amazon architecture in an interview is fine - as long as you acknowledge the scale difference. "Netflix uses a service mesh for east-west traffic management, and at the scale described in this problem - 50 million users, 200+ services - I think a service mesh is justified for the same reasons" is a strong answer. "I would use a service mesh because Netflix does" is a weak answer. The interviewer is testing whether you can reason about applicability, not whether you have read the blog post.

The Decision Matrix for Interviews

In an interview setting, you do not have time to walk through all five criteria explicitly. Here is the compressed version you can deliver in 30 seconds:

Tip: The compressed interview phrasing: "Given the scale of this system - [X users, Y transactions per second] - and the fact that these components have different scaling and consistency requirements, I think a microservices architecture is appropriate. The order processing needs strong consistency, the search needs high read throughput with eventual consistency, and the notification system has a completely different traffic pattern. Separating them allows each to scale and evolve independently."

That framing takes 20 seconds and checks three criteria: scale, differential requirements, and independent evolution. It is enough to justify the architecture choice and move on to decomposition.

The Hybrid Path - Selective Decomposition

The decision is not always all-or-nothing. In practice, many successful architectures are hybrids - a monolithic core with specific components extracted into services where independence is genuinely needed.

For example, a food delivery platform might start as a monolith and then extract:

1. The payment service - because PCI compliance requires isolation and the payment team has a different deployment approval process
2. The notification service - because it handles 100x the traffic of the rest of the system and needs independent scaling
3. The delivery tracking service - because it requires real-time event processing with a different technology stack

The rest of the system - order management, restaurant management, menu management, user management - remains a monolith because it does not have the differential requirements that justify the overhead of separation.

This selective approach is often the right answer in interviews too. Not "I would decompose everything into microservices" but "I would extract these three components because they have specific needs that justify independence, and keep the rest as a cohesive service." That demonstrates the judgment to decompose where it matters and to avoid decomposition where it does not.

graph TD
    subgraph Mono["Monolithic Core"]
        OM["Order\nManagement"]
        RM["Restaurant\nManagement"]
        MM["Menu\nManagement"]
        UM["User\nManagement"]
    end
    
    subgraph Extracted["Extracted Services"]
        PS["Payment Service\n(PCI Isolation)"]
        NS["Notification Service\n(Independent Scaling)"]
        DT["Delivery Tracking\n(Real-time Processing)"]
    end
    
    Mono <-->|"API"| PS
    Mono <-->|"Events"| NS
    Mono <-->|"Events"| DT

This diagram shows a hybrid architecture with a monolithic core containing order management, restaurant management, menu management, and user management. Three services are extracted: a payment service for PCI isolation, a notification service for independent scaling, and a delivery tracking service for real-time processing. The core communicates with extracted services through APIs and events.

Interview: The hybrid answer is often the strongest answer. It shows the interviewer you can identify which components need microservices treatment and which do not. "I would keep the core as a modular monolith and extract payment, notification, and tracking as independent services because..." is a more sophisticated answer than "I would decompose into 15 microservices." Fewer, well-justified boundaries signal stronger architectural judgment than more, poorly-justified ones.

What Comes Next

This lesson gave you the framework for deciding whether to use microservices. The next lesson places microservices in the broader architectural taxonomy - how they relate to SOA, service-based architecture, and other distributed architectural styles. Understanding where microservices fit in that spectrum helps you use the right vocabulary in interviews and avoid the common mistake of conflating microservices with every form of service decomposition.

Back to Microservices Interview