Splitting one giant program into many small services is easier to imagine than to run — keeping track of ten small boxes really is harder than keeping track of one big one. That difficulty is what this whole guide unpacks.

Imagine a toy box. You could keep every toy — cars, blocks, dolls, puzzles — in one giant box. It is simple to carry: one box, one lid. But when you want just the puzzle, you have to dig through everything else. And if the box splits at the bottom, every toy falls out at once.

Now imagine you keep each kind of toy in its own small box: one box for cars, one for blocks, one for puzzles. You can carry just the puzzle box to a friend’s house. If the car box breaks, your puzzles are still fine. But now you have to keep track of ten boxes instead of one, remember where each one is, and make sure they do not get lost.

That is, in plain words, the entire microservices story. The “one giant box” is called a monolith. The “many small boxes” architecture is called microservices. This tutorial is about the second half of that story — the part people forget to mention: keeping track of ten boxes is genuinely harder than keeping track of one. That difficulty is the disadvantage we are here to understand, deeply and precisely.

A little bit of history

In the 1990s and 2000s, most software was built as a monolith: one large program containing all the code — the website, the payment logic, the inventory logic, the email logic — compiled and deployed together as a single unit. This worked well when teams were small and traffic was modest.

As companies like Amazon, Netflix, and eBay grew massively in the 2000s and early 2010s, their monoliths grew too — into millions of lines of code maintained by hundreds of engineers. Deploying a single small change meant redeploying the entire application, and one bug in the “shipping label” code could crash the “checkout” feature too, because everything shared the same process and memory.

Around 2011–2014, the term “microservices” was popularised (notably by James Lewis and Martin Fowler, who wrote an influential 2014 article describing the pattern) to describe what companies like Netflix and Amazon were already doing in practice: splitting one big application into many small, independently deployable services, each owning one business capability, talking to each other over a network.

This tutorial assumes zero prior knowledge, so every new term below is explained plainly, with an everyday analogy first and a technical example second.

Before naming a disadvantage of microservices, it helps to remember the pain they replaced — the pain of the monolith. That way “microservices are complicated” reads as a trade, not a mistake.

Before we can understand a disadvantage of microservices, we must understand the disadvantage of the thing they replaced — the monolith. Otherwise “microservices are complicated” sounds like a reason never to use them, which is not true; it is a trade, not a mistake.

What is a monolith?

Problems that appear as a monolith grows:

• Slow deployments — even a one‑line fix to the “Payments” page requires rebuilding and redeploying the whole app.
• Scaling is wasteful — if only the “search” feature is under heavy load, you still have to scale the entire monolith (including parts nobody is using right now), which wastes computing resources and money.
• One team’s bug can freeze everyone — a memory leak in “recommendations” can crash the whole process, taking down checkout too.
• Codebase becomes a “big ball of mud” — over years, everything gets tangled, and new engineers take months to become productive.

What is a microservice?

What it is: a microservice is a small, independently deployable program that owns one specific business capability (e.g., “manage orders”) and exposes that capability to other programs through a well‑defined interface, usually a network API.
Why it exists: to let each capability be built, deployed, scaled, and even rewritten separately, by a separate team, without needing to touch or even understand the other capabilities.
Where it is used: Netflix (hundreds of services), Amazon (thousands), Uber, Spotify, Airbnb, and most large‑scale modern cloud platforms.

A short vocabulary before we go deeper — each term with what it is, why it exists, an analogy, and a small example.

1. Service boundary

What: the invisible line that decides what belongs inside a microservice and what does not.
Why: without a clear boundary, services start depending on each other’s internal details, and you lose the benefits of splitting them up in the first place.

2. API (Application Programming Interface)

What: a defined set of rules describing how one program can request something from another program.
Why: it lets two services built by different teams, in possibly different languages, talk to each other reliably, without knowing each other’s internal code.
Example: the Order Service exposes GET /orders/{id}. Any other service, written in Java, Python, or Go, can call this URL and get order data back as JSON.

3. Network call (a.k.a. Remote Procedure Call)

What: sending a request over the network (Wi‑Fi, cables, the internet) to another machine or process, and waiting for a reply.
Why it matters here: a network call can be slow (milliseconds instead of nanoseconds), can fail halfway (the reply gets lost), and can time out (no answer at all) — none of which can happen with a normal function call inside one program.

4. Bounded context

What: a term from Domain‑Driven Design (DDD) meaning “the area of the business where a specific model and vocabulary apply.” For example, the word “Customer” might mean something slightly different in the Billing service versus the Shipping service.
Why it exists: it gives teams a principled way to decide where one microservice ends and another begins — usually one microservice per bounded context.

5. Data consistency

What: the guarantee that data is correct and matches reality across the whole system, not just in one place.
Why it’s hard in microservices: each service has its own database. If Order Service marks an order “paid” but Payment Service’s database still says “pending” (because the network call between them failed), the system is now inconsistent — two “truths” disagree.

6. CAP theorem (a foundational rule for distributed systems)

What: a theorem stating that a distributed data system can only fully guarantee two of these three properties at the same time, during a network failure:

• C — Consistency: every read gets the latest write.
• A — Availability: every request gets a (non‑error) response.
• P — Partition tolerance: the system keeps working even if network messages between machines are lost or delayed.

Why it matters: since real networks do experience partitions (a switch fails, a data centre loses power), Partition tolerance is not optional in practice — so real distributed systems (which is what a microservices architecture is) must choose between Consistency and Availability when a partition happens. Monoliths mostly avoid this problem because everything lives in one place; microservices are forced to face it directly.

7. Latency

What: the time it takes for a request to travel and come back with a response.
Why it grows in microservices: one user action might now require five services to call each other in sequence, and each network hop adds a few milliseconds — sometimes tens of milliseconds under load.

8. Container & orchestration

What: a container (e.g., Docker) packages a service with everything it needs to run. An orchestrator (e.g., Kubernetes) automatically starts, stops, restarts, and scales many containers across many machines.
Why it exists: with dozens or hundreds of microservices, you cannot manually manage each one — you need automation.

A realistic microservices system has more moving parts than just “services.” Most of these extra components exist purely to make the many small services work together safely — in a monolith they simply do not need to exist.

Trace one ordinary action — “place an order” — through a microservices system, step by step, so the internal working is concrete rather than abstract.

Step by step, in plain words

1. 1. The user taps “Buy Now” on the app.

   Nothing unusual so far — the same as every other architecture.

2. 2. The request reaches the API Gateway.

   The gateway checks who the user is and forwards the request onward.

3. 3. Order Service receives it.

   Two things must be confirmed before it can say “success”: the item is in stock, and the payment goes through.

4. 4. Order calls Inventory Service over the network and waits.

   First blocking hop.

5. 5. Order calls Payment Service over the network and waits.

   Second blocking hop.

6. 6. Only if both replies are successful does Order mark the order “confirmed” and reply back through the gateway.

   The user finally sees a response.

7. 7. Afterwards, Order publishes an event to a message queue.

   The Notification Service picks it up and sends a confirmation email. This part does not need to happen before the user sees “success,” so it is done asynchronously.

To keep the trade‑off honest, here are the real benefits microservices provide — these are exactly what the coming disadvantages are the price for.

• Independent deployment — teams ship their own service without waiting for others, or coordinating a “big bang” release.
• Independent scaling — scale only the “Search” service on Black Friday, not the whole system.
• Technology freedom — one team can use Java, another can use Go or Python, whatever fits their problem best.
• Fault isolation — in principle, a crash in Recommendations does not have to take down Checkout.
• Smaller, understandable codebases — a new engineer can learn one service in days, not one giant monolith in months.
• Organisational scaling — hundreds of small teams can work in parallel with minimal collision (this maps to Conway’s Law: system architecture tends to mirror team structure).

Every one of these benefits is bought by adding a network boundary between things that used to be one program. That network boundary is exactly where the cost hides — and that cost is what the rest of this tutorial unpacks in full detail.

If someone asks “what is a disadvantage of microservices?” — here is the single best one‑sentence answer, followed by the full explanation and its ten concrete branches.

This single root cause branches out into many concrete, specific problems. Interviewers — and real production incidents — usually want the specifics, not just the headline.

7.1 — Increased operational complexity

What it is: running ten small programs is operationally harder than running one big program, even though each small program is individually simpler.

Concretely: with one monolith, you deploy one artifact, monitor one process, and manage one set of logs. With fifty microservices, you deploy fifty artifacts (each possibly on its own schedule), monitor fifty processes, and correlate fifty separate log streams — usually across many machines and containers.

7.2 — Distributed data consistency (the hardest one)

What it is: each microservice typically owns its own private database (database‑per‑service), so there is no longer one shared database transaction that can atomically update several tables at once across service boundaries.

Example (from Section 5): Inventory Service successfully reserves stock, but the Payment Service call fails. Now stock is reserved for an order that was never paid for — an inconsistency that must be detected and fixed by extra logic (compensating actions), because there was no single database transaction wrapping both steps.

Engineers solve this with patterns like the Saga pattern (Section 15) and by accepting eventual consistency (the idea that the system will become correct eventually, a few seconds or minutes later, rather than instantly) — a mental model monolith developers rarely needed.

7.3 — Network unreliability becomes a core design concern

What it is: every inter‑service call can be slow, can time out, can partially fail (request sent but response lost), or can arrive out of order.

This is formalised in software engineering as the “Fallacies of Distributed Computing” (an old, still‑true list from Sun Microsystems engineers), including false assumptions like “the network is reliable,” “latency is zero,” and “bandwidth is infinite” — none of which are true, and all of which a microservices developer must design around, but a monolith developer usually never has to think about at all.

7.4 — Testing becomes much harder

What it is: to fully test one user action end‑to‑end, you may need several services running simultaneously and talking correctly to each other — not just one program.

Teams address this with contract testing (each service tests that it honours an agreed “contract” with its callers, without needing every other service actually running) and service virtualisation (fake stand‑ins for other services during tests), but these are extra tools and extra discipline that a monolith simply does not need.

7.5 — Debugging and tracing a single failure is harder

What it is: when something goes wrong, the root cause might be three services away from where the symptom appeared.

This is why distributed tracing (Section 11) — tools that stitch together a request’s full journey with a shared trace ID — became essentially mandatory for microservices, whereas a monolith developer could usually just read a single stack trace.

7.6 — Increased latency from network hops

What it is: every extra network call adds delay. A user action that needed one in‑memory function call in a monolith might need five sequential network calls in microservices, each adding a few milliseconds — and under load, sometimes much more.

We quantify this properly with real numbers in Section 8.

7.7 — Deployment and infrastructure overhead

What it is: each service typically needs its own build pipeline, its own container image, its own health checks, its own scaling rules, and its own configuration — multiplied by however many services exist.

A team running 5 services multiplies almost every “one‑time” operational task by 5. A team running 300 services (realistic at Amazon‑scale companies) multiplies it by 300. This is why strong automation (CI/CD, Kubernetes) is not optional in microservices — it is a survival requirement.

7.8 — Larger security surface area

What it is: every network boundary between services is also a place where an attacker could try to intercept, impersonate, or inject bad data — something that does not exist inside a single process’s memory space.

Full detail in Section 10.

7.9 — Organisational & cognitive overhead

What it is: engineers must now understand not just “my service” but also which other services it depends on, what their contracts are, and how failures propagate — a wider mental model than “just my module” in a monolith.

7.10 — Higher infrastructure cost

What it is: running many small services often means many small servers or containers, each with baseline overhead (its own runtime, its own memory footprint, its own monitoring agent), which can add up to more total resource usage than one efficiently‑packed monolith, especially at smaller scale.

Microservices scale specific hot paths well, but each network hop is a serialisation step, a network trip, and a deserialisation step — work that simply does not exist in an in‑process call.

Scalability upside: you can scale exactly the service under load — e.g., during a flash sale, scale only Product Service and Order Service, not Auth or Notifications, saving cost and giving faster, more targeted scaling.

Performance downside: latency accumulates across hops. Consider this rough (illustrative) comparison:

These numbers are illustrative, not universal — real numbers vary hugely by network quality, service load, and whether calls run in parallel or sequence. The lesson is structural: each network hop is a serialisation step (turning objects into JSON/bytes), a network trip, and a deserialisation step — work that simply does not exist in a function call within one process.

How teams mitigate this

• Parallelise independent calls instead of calling services one after another when they do not depend on each other.
• Caching — store frequently‑read data (like product details) close to where it is needed, so not every request needs a fresh network round trip (Section 13).
• Asynchronous / event‑driven calls — do not make the user wait for steps that can happen in the background (like sending an email).
• gRPC or binary protocols instead of verbose JSON‑over‑HTTP, to cut serialisation time in high‑throughput internal calls.

One slow service can drag its neighbours down with it — unless you defend against that possibility explicitly with circuit breakers, timeouts, retries, and bulkheads.

Cascading failure

What it is: when one slow or broken service causes the services that depend on it to also become slow or broken, spreading like a chain reaction.

Circuit breaker pattern (the standard fix)

What it is: a safety mechanism that “trips” (like an electrical circuit breaker in your home) and stops calling a failing service for a while, instead immediately returning a fallback response, giving the failing service time to recover instead of being hit with more requests.

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
    .failureRateThreshold(50)                        // trip if 50% of calls fail
    .waitDurationInOpenState(Duration.ofSeconds(10)) // pause 10s before retrying
    .slidingWindowSize(20)                           // look at the last 20 calls
    .build();

CircuitBreaker breaker = CircuitBreaker.of("inventoryService", config);

Supplier<StockStatus> decorated = CircuitBreaker
    .decorateSupplier(breaker, () -> inventoryClient.checkStock(itemId));

StockStatus result = Try.ofSupplier(decorated)
    .recover(throwable -> StockStatus.unknownFallback())
    .get();

Here, if the Inventory Service starts failing too often, the circuit “opens” and further calls immediately return a safe fallback (unknownFallback()) instead of hammering an already‑struggling service — protecting both services and giving the system a chance to recover instead of collapsing entirely.

Retries, timeouts, and bulkheads

• Timeout: give up waiting after a fixed time instead of waiting forever.
• Retry (with backoff): try again after a short, increasing delay — but only for safe, “idempotent” operations (ones that do not cause harm if repeated).
• Bulkhead: limit how many concurrent calls can go to one dependency, so one slow dependency cannot consume all available threads or connections (named after ship compartments that stop one flooded section from sinking the whole ship).

Every network boundary is a new door — and every new door needs its own lock. Microservices multiply the number of doors, which multiplies the security work.

In a monolith, most communication happens inside one process’s memory — invisible to the outside network. In microservices, communication happens over the network between services, even inside your own data centre (“east‑west traffic”), which introduces new attack surfaces:

• Service‑to‑service authentication — you must verify that a request really came from the legitimate Order Service, not an impostor, using things like mutual TLS (mTLS) or short‑lived tokens.
• More network endpoints to secure — each service exposes its own API, meaning more doors that must each be locked properly.
• Secrets sprawl — database passwords, API keys, and certificates now need to be managed and rotated across many services instead of one config file.
• Harder‑to‑audit access — tracking “who can call what” across dozens of services is more complex than one access‑control list in one app.

Modern mitigation: a service mesh (like Istio or Linkerd) can automatically enforce mTLS and access policy between services, so individual developers do not need to hand‑roll security in every service.

Because a single user action can touch many services, monitoring must evolve to follow requests across them — traces, centralised logs, and metrics stitched together in one place.

Distributed tracing

What it is: a system that tags every request with a unique trace ID at the very first entry point, and every service passes that same ID forward and records its own timing under it — so you can later see the entire journey of one request across every service it touched.

Centralised logging

What it is: instead of reading log files on fifty different machines, all services ship their logs to one central place (e.g., an ELK stack — Elasticsearch, Logstash, Kibana — or a hosted alternative) so you can search across everything at once.

Metrics & dashboards

What it is: numeric measurements over time — request rate, error rate, latency percentiles (like “95% of requests finish under 200 ms”) — collected per service and displayed on dashboards (commonly Prometheus for collection, Grafana for visualisation).

Once you are past a handful of services, container orchestration is close to mandatory — and blue‑green, canary, and rolling deployments become the everyday tools for shipping safely.

What changes: instead of one deployment pipeline, you typically need one pipeline per service (though templated / shared pipelines reduce duplication). Container orchestration (typically Kubernetes) becomes close to mandatory once you are past a handful of services, because manually starting, restarting, and scaling dozens of processes by hand is not sustainable.

Common deployment strategies used to reduce risk

• Blue‑green deployment: run the old version (“blue”) and new version (“green”) side by side, then switch traffic over instantly, keeping the old version ready as an instant rollback.
• Canary deployment: send a small percentage (e.g., 5%) of real traffic to the new version first, watch for errors, then gradually increase.
• Rolling update: replace old instances with new ones a few at a time, so the service never goes fully offline.

Cost of this convenience: all of this — orchestration, pipelines, canary tooling, service meshes — is infrastructure a monolith usually does not need at all. It is powerful, but it is also a genuine, ongoing operational and learning cost.

The database‑per‑service rule is what keeps services truly independent — and losing cross‑table SQL joins is a direct, unavoidable consequence of that rule.

Database‑per‑service

What it is: best practice says each microservice should own its own private database, which no other service is allowed to query directly.
Why: it keeps services truly independent — a schema change in Order Service’s database cannot accidentally break Payment Service, because Payment Service was never allowed to touch Order’s tables directly.
The cost: no more simple cross‑table SQL joins across, say, Orders and Payments. If you need combined data, you must fetch it via API calls (slower) or maintain a separate read‑optimised copy (more complexity) — this is a direct, unavoidable consequence of splitting the data, not just the code.

Caching

What it is: temporarily storing a copy of frequently‑needed data somewhere fast to access (often in memory, using tools like Redis), so you do not repeat an expensive database query or network call every single time.

New problem this introduces: cache invalidation — knowing when the sticky note is out of date and needs updating. This is famously one of the two hardest problems in computer science (the joke being: “there are only two hard things in computer science: cache invalidation, naming things, and off‑by‑one errors”).

Load balancing

What it is: distributing incoming requests across multiple running copies (instances) of the same service, so no single instance gets overwhelmed.

Common algorithms:

• Round robin: send requests to each instance in turn, like dealing cards one at a time.
• Least connections: send the next request to whichever instance currently has the fewest active requests.
• Weighted / latency‑based: send more traffic to faster or more powerful instances.

Microservices are only as good as the contracts between them. Two practical challenges — versioning and sync vs. async — dominate real production work.

Versioning

What it is: when Order Service changes its API (e.g., renames a field), every other service calling it must be updated too — or the old version must be kept running alongside the new one until every caller has migrated.

@RestController
@RequestMapping("/api/v2/orders")
public class OrderControllerV2 {

    @GetMapping("/{id}")
    public ResponseEntity<OrderResponseV2> getOrder(@PathVariable String id) {
        Order order = orderService.findById(id);
        // v2 adds a new "estimatedDelivery" field without breaking v1 clients
        return ResponseEntity.ok(OrderResponseV2.from(order));
    }
}

Keeping /api/v1/orders alive alongside /api/v2/orders lets old clients keep working while new clients adopt the new shape — but now you are maintaining two versions of the same logic, which is more work than maintaining one.

Synchronous vs. asynchronous communication

Sagas, API gateways, circuit breakers, and the Strangler Fig migration — the seatbelts that make microservices survivable — alongside the anti‑patterns (distributed monolith, chatty services, shared database) that quietly undo them.

Pattern: Saga

What it is: a way to manage a multi‑step business transaction that spans several services, where each step has a matching “undo” step (a compensating action), used instead of one shared database transaction.

public class PlaceOrderSaga {

    public void execute(OrderRequest request) {
        boolean stockReserved = false;
        try {
            inventoryClient.reserveStock(request.getItemId(), request.getQty());
            stockReserved = true;

            paymentClient.charge(request.getUserId(), request.getAmount());

            orderRepository.markConfirmed(request.getOrderId());
        } catch (PaymentFailedException e) {
            if (stockReserved) {
                inventoryClient.releaseStock(request.getItemId(), request.getQty());
            }
            orderRepository.markFailed(request.getOrderId());
        }
    }
}

Pattern: API Gateway

Covered in Section 4 — a single, controlled entry point that hides internal service topology from clients.

Pattern: Circuit Breaker & Bulkhead

Covered in Section 9 — protects the system from cascading failure.

Pattern: Strangler Fig (migration pattern)

What it is: a gradual way to migrate a monolith into microservices by slowly routing individual features to new services one at a time, while the old monolith still handles everything else, until eventually nothing is left in the monolith (named after a vine that slowly grows around a tree until the original tree is gone).

Anti‑pattern: The “Distributed Monolith”

Anti‑pattern: Chatty services

What it is: splitting things so finely that completing one simple action requires dozens of tiny network calls back and forth between services, multiplying latency for no real benefit.

Anti‑pattern: Shared database

What it is: multiple “independent” services secretly reading and writing the same database tables. This silently re‑creates monolith‑style coupling (a schema change breaks multiple services) while still paying the network cost of separate deployments.

Seven habits that keep the microservices tax manageable — and six mistakes that quietly turn a microservices project into a distributed monolith.

Companies that made microservices work at huge scale — and companies that publicly moved specific workloads back towards simpler designs after finding the tax too high for that particular problem.

The questions people ask most about microservices disadvantages — plus a few interview‑style bonuses for readers preparing for system‑design rounds.

Bonus: interview‑style questions

Microservices are not a mistake to avoid; they are a trade to make consciously. The seven ideas below are the shortest honest answer to “what is a disadvantage of microservices?”

The systems that hold up over years are almost always the ones whose engineers treated microservices as a trade, not as a badge — deciding in each case whether the independent deployment, independent scaling, and organisational autonomy were worth the well‑documented tax of distributed complexity. The disadvantages in this guide are not warnings against microservices; they are the honest ticket price for the seat.