What Is the Main Advantage of Microservices Over a Monolith?
A complete, from‑zero, book‑style tutorial — with analogies, diagrams, Java code, and real production stories from Netflix, Amazon, and Uber. By the end, you will be able to explain this confidently in an interview, on a whiteboard, or to a curious ten‑year‑old.
Introduction & A Short History
Imagine you own a shop. In the beginning, it is a small shop, and you sell everything — bread, milk, toys, shoes — from one counter, run by one person: you. This is simple. You can see everything at once. If a customer wants bread, you walk to the bread shelf. Easy.
Now imagine your shop becomes famous. Thousands of customers show up every day. You hire more people, but everyone is still crammed behind the same one counter, tripping over each other. If the toy shelf catches fire, the whole shop has to close — even the bread counter, even though bread had nothing to do with the fire. If you want to repaint just the shoe section, you have to shut the entire shop for the day.
This is the exact story of software applications over the last 25 years. In the beginning, we built one big program — a monolith — that did everything: user login, product catalog, payments, shipping, notifications, all living in a single codebase, built together, tested together, and deployed together as one giant unit. It worked beautifully when the “shop” was small.
But as companies like Amazon, Netflix, Uber, and eBay grew from small shops into massive supermalls serving millions of customers a day, the single‑counter model started breaking down. Teams stepped on each other’s code. A tiny bug in the “recommendation” feature could crash the entire “checkout” system. Deploying a one‑line fix meant re‑testing and re‑releasing the entire application, which could take hours or days.
So engineers asked a question: what if, instead of one giant shop, we built a small mall — a collection of small, independent shops, each responsible for one thing, each with its own staff, its own cash register, and its own opening hours — all standing next to each other, connected by walkways? That question is the seed of microservices architecture.
A short history
Microservices were not invented because they are “trendy.” They were invented to solve a real, painful problem: large teams working on one giant codebase move slower and slower over time. Keep that problem in mind — it is the key to understanding the “main advantage” this tutorial is built around.
The Problem & Motivation
Before we can appreciate the solution, we must feel the pain of the problem. Let us build a monolith in our heads, step by step, and watch it get harder to manage.
Meet “ShopEasy” — an online store
Imagine a small startup builds an online store called ShopEasy. In year one, three developers write one application containing:
- User Service logic — sign up, log in, manage profile
- Catalog logic — list products, search, show details
- Cart & Checkout logic — add to cart, calculate totals
- Payment logic — charge credit cards
- Shipping logic — calculate delivery dates, print labels
- Notification logic — send emails and SMS
All of this lives in one codebase, compiled into one program, running as one process, deployed as one unit (say, one .jar file on one or many identical servers). This is a monolith.
For the first year, this is great. One codebase is easy to understand. One deployment pipeline. One database to manage. Three developers can hold the whole system in their heads.
Year three: growth brings pain
Now ShopEasy has grown. There are 80 developers split into 10 teams. Each team owns a “module” inside the same giant codebase — but it is still one codebase, one build, one deployable unit. Watch what starts to happen:
- Slow builds: compiling the entire application now takes 25 minutes. Every developer waits 25 minutes to see if their one‑line change works.
- Scary deployments: to ship a tiny fix to the Notification module, the entire application — including Payments — must be re‑tested and re‑deployed. A mistake anywhere can bring down everything.
- Blast radius: a memory leak in the “Recommendation” feature slowly eats up RAM until the whole process crashes — including Checkout and Payments, which had nothing to do with the leak. This is called a large blast radius — one small fire burns the whole building.
- Scaling waste: during a big sale, the Catalog and Cart modules need 10x more computing power because everyone is browsing and buying. But since everything is bundled into one process, you must scale the entire monolith — including parts like “Admin Reports” that nobody is using at 2 a.m. That is like turning on the air conditioning in every single room of a huge mansion just because one person is hot in the kitchen.
- Technology lock‑in: the whole application is written in one language (say, Java) using one framework version. If the Search module would work far better with a specialised search technology, tough luck — everything must stay compatible with the rest of the monolith.
- Team collisions: ten teams pushing code into the same repository constantly create “merge conflicts” (two people editing the same file differently) and long code‑review queues. Team velocity — how fast a team can ship — starts to shrink, not because people got lazier, but because the system got tangled.
One big kitchen, ten chefs. If all ten chefs must share one stove, one cutting board, and one fridge, they spend more time waiting for their turn and bumping into each other than actually cooking. Adding an eleventh chef does not just fail to help — it can make everyone slower.
The core motivation
The motivation behind microservices is not “microservices are cooler.” It is: as software and teams grow, coupling everything into one deployable unit creates a bottleneck that gets worse — not better — as you add more people and features. Microservices exist to remove that bottleneck by giving each team its own small, independent “kitchen.”
Core Concepts
Let us carefully define every term we will use throughout this tutorial. No jargon left unexplained.
Monolith
What it is: A software application built and deployed as a single, unified unit. All features live in one codebase and run inside one process (or many identical copies of that one process).
Why it exists: It is the natural, simplest way to build software — write code, put it in one project, run it.
Where it is used: Startups, small applications, internal tools, and many successful large systems that do not need to split (not every big company uses microservices!).
Analogy: A department store — one building, one roof, one set of doors, everything under single management.
Practical example: A single Spring Boot Java application (one .jar) that contains controllers, services, and repositories for users, products, orders, and payments — all compiled into one artifact.
Microservices
What it is: An architectural style where an application is built as a collection of small, independent services. Each service focuses on one business capability (like “Payments” or “Shipping”), owns its own data, and can be developed, deployed, scaled, and even rewritten independently of the others.
Why it exists: To let many teams work on the same overall product without stepping on each other, and to let each part of the system scale and fail independently.
Where it is used: Large‑scale systems with many teams — Netflix, Amazon, Uber, Spotify, and thousands of modern SaaS products.
Analogy: A shopping mall — many small shops, each with its own staff and hours, connected by shared walkways (a “network”).
Practical example: Instead of one .jar, ShopEasy becomes six small applications: user-service, catalog-service, cart-service, payment-service, shipping-service, and notification-service — each with its own codebase, its own database, and its own deployment schedule.
Service
What it is: One independently running unit of software that does one job and exposes that job to others through a well‑defined interface (usually an API over a network).
Why it exists: To create a clear boundary of responsibility — “this service owns Payments, that is it.”
Analogy: One shop in the mall, like “Joe’s Shoe Repair” — it does exactly one thing, and you interact with it through its counter (its “interface”), not by walking behind and touching its tools yourself.
Coupling & Cohesion
What it is: Coupling measures how much one part of a system depends on the internal details of another part. Cohesion measures how strongly the responsibilities inside one part belong together.
Why it matters: Good architecture wants low coupling (parts do not need to know each other’s secrets) and high cohesion (related things stay together). Microservices are, at their heart, a technique to enforce low coupling between business capabilities and high cohesion within each one.
Analogy: A toy with detachable LEGO blocks (low coupling, easy to swap one piece) versus a toy carved from a single block of wood (high coupling, you cannot change one part without reshaping the whole thing).
API (Application Programming Interface)
What it is: A defined way for one piece of software to ask another piece of software to do something, without needing to know how it works internally.
Why it exists: So services (or any two programs) can cooperate through a stable “contract” instead of reading each other’s source code.
Analogy: A restaurant menu. You (the customer) do not need to know how the kitchen cooks the food — you just need the menu (the API) to place your order and know what you will get back.
Deployment Unit
What it is: The smallest piece of software that gets shipped (“deployed”) together, all at once, as one unit.
Why it matters: In a monolith, the deployment unit is the entire application. In microservices, the deployment unit is one service. This single difference is the root cause of almost every advantage and disadvantage we will discuss.
Bounded Context
What it is: A term from Domain‑Driven Design (DDD) meaning a clear boundary within which a specific business concept (like “Order”) has one consistent meaning and one owner.
Why it exists: To decide where to cut when splitting a monolith into services. Each microservice should map to one bounded context.
Analogy: In a hospital, the word “patient” means something slightly different to the Billing department (a customer with a bill) than to the Surgery department (a body needing care). Each department is a bounded context with its own version of “patient.”
Architecture & Components
Let us zoom into what a real microservices system looks like, piece by piece.
Key components explained
The single front door
A gateway that all client requests pass through before being routed to the correct backend service. Without it, your mobile app would need to know the network address of every microservice, handle authentication itself, and manage dozens of separate connections. The gateway hides that complexity. Like the receptionist at a big office building — you tell them “Dr. Smith in Room 304” and they direct you. Tools: Amazon API Gateway, Kong, NGINX, Spring Cloud Gateway.
Finding a moving target
A directory that keeps track of which services are currently running and at what network address. In the cloud, services start, stop, crash, and get replaced constantly, often getting new IP addresses each time — hard‑coding addresses would break all the time. Like a hotel’s front desk that always knows which room each guest is currently staying in. Tools: Netflix Eureka, HashiCorp Consul, Kubernetes’ built‑in service discovery.
A shared bulletin board
A middleman that lets services send messages (“events”) to each other without talking directly, and without waiting for an immediate reply. The sender does not need to know who is listening. Like a bulletin board in a school hallway — a teacher pins a notice, any student who cares can read it whenever they walk by. Tools: Apache Kafka, RabbitMQ, Amazon SNS/SQS.
Invisible traffic police
An infrastructure layer that manages service‑to‑service communication (retries, encryption, traffic routing) without services needing to code that logic themselves. Like invisible traffic police standing at every intersection of the mall’s walkways, quietly directing foot traffic, without shoppers even noticing. Tools: Istio, Linkerd.
Private storeroom per shop
Every microservice manages its own private data store, which no other service is allowed to access directly. This is what makes services truly independent — if Team A wants to change the shape of their database table, they can, as long as their API still behaves the same way. Like each shop keeping its own cash register and stockroom; the bakery does not open the shoe shop’s till.
Beginner example: A student project splits a “TodoApp” into task-service (create/list tasks) and user-service (login/signup), each a small Spring Boot app on a different port, talking over plain REST calls.
Production example: Netflix runs 700+ microservices, using Eureka for discovery, Zuul / Spring Cloud Gateway as the API gateway, Kafka for streaming events, and Hystrix (and later resilience4j) to prevent one failing service from cascading into others.
Internal Working — What Actually Happens
Let us walk through, step by step, what happens technically when microservices work together — versus what happens in a monolith — using a concrete example: “Place an Order.”
Inside a monolith
One HTTP request
The browser sends one HTTP request: POST /order to the single application server.
In‑memory Java call
Inside the same process, the Order module calls a Java method directly on the Payment module — a normal, in‑memory function call. This is extremely fast (nanoseconds) and always “reliable” in the sense that it either fully works or the whole process crashes.
Another in‑memory call
The Payment module calls the Shipping module the same way — an in‑memory method call.
One atomic transaction
Everything happens inside one database transaction — if anything fails, the database can roll back everything at once using ACID guarantees.
One HTTP response
One HTTP response goes back to the browser.
Inside microservices
Request hits the gateway
The browser sends POST /order to the API Gateway.
Auth check and routing
The Gateway authenticates the request (often by asking the Auth service or validating a token) and routes it to the Order Service over the network.
Network call to Payment
The Order Service does not have direct access to Payment’s code or database. It must make a network call (like an HTTP request or a message) to the Payment Service, asking, “please charge $49.99 to this customer.”
Failure modes appear
This network call can be slow (milliseconds instead of nanoseconds), can time out, or can fail entirely if the Payment Service is down, overloaded, or being deployed at that exact moment.
No single transaction
Because Order and Payment have separate databases, there is no single database transaction covering both. If Payment succeeds but the network response gets lost on the way back, the Order Service might think it failed. This requires careful patterns (like the Saga pattern) to keep data consistent.
Publish an event
Once Payment confirms, the Order Service might publish an event (“OrderPaid”) onto the message broker. The Shipping Service, listening for that event, picks it up later and starts preparing the shipment — completely independently, at its own pace.
Fast response, later work
The client gets a response, often before shipping has even started, because shipping happens asynchronously in the background.
In a monolith, it is like one person doing every step of making a burger themselves — buying the bun, grilling the patty, and wrapping it — all with their own two hands, in one place. In microservices, it is like a fast‑food kitchen with separate stations: the grill station cooks the patty and slides it down a conveyor belt (the event bus) to the assembly station, which does not need to talk directly to the grill cook — it just waits for patties to arrive.
Data Flow & Lifecycle
Let us trace the full lifecycle of one piece of data — a customer’s order — as it flows through a microservices system from birth to completion.
Two important lifecycle ideas
Synchronous vs Asynchronous communication
Synchronous means Service A calls Service B and waits for the answer before continuing — like a phone call. Asynchronous means Service A sends a message and moves on immediately, and Service B processes it whenever it is ready — like sending a text message or leaving a voicemail.
Microservices typically use synchronous calls (often REST or gRPC) for things that need an immediate answer (e.g., “is this credit card valid?”), and asynchronous events (via a message broker) for things that can happen later (e.g., “prepare the shipment” or “log this for analytics”).
Eventual Consistency
What it is: A guarantee that, given enough time (usually milliseconds to seconds), all parts of the system will agree on the current state of the data — even though, for a brief moment, they might disagree.
Why it exists: Because microservices do not share one database or one transaction, it is often impossible (and too slow) to force instant agreement everywhere. So systems accept a short delay instead.
Analogy: When you change your address with the post office, it might take a day or two before every mail carrier’s route sheet is updated. For a short window, some carriers still have your old address — but eventually, everyone catches up.
The Main Advantage — The Core Answer
Now we arrive at the heart of this tutorial. If an interviewer, a professor, or a curious friend asks you: “What is the main advantage of microservices over a monolith?” — here is the single best one‑sentence answer, followed by the full explanation.
The main advantage of microservices is independent deployability and scalability — the ability to develop, deploy, scale, and fix each part of the system on its own, without touching or redeploying the rest of the application.
Every other benefit you will read about (fault isolation, technology freedom, team autonomy, faster releases) is really a consequence of this one root idea: each service is its own independent deployment unit. Let us unpack why this single property is so powerful.
Why “independent deployability” is the root cause of everything good
| Because services deploy independently… | …this becomes possible |
|---|---|
| Team A can ship a fix to Payments on Tuesday at 2 p.m. | Team B does not need to test or approve anything — faster releases |
| Only the Payment Service process crashes | Catalog, Login, and Shipping keep working — fault isolation |
| Only Catalog needs 50 servers during a sale | You do not waste money running 50 copies of Payments too — targeted, cost‑efficient scaling |
| The Search team wants to use a different database | They can, since no one else touches their database — technology freedom |
| A new hire only needs to understand one small service | Onboarding is faster, codebases stay small — cognitive simplicity per team |
A concrete before / after story
Recall ShopEasy from Chapter 2. Before splitting into microservices, fixing a typo in an email template required rebuilding and redeploying the entire 25‑minute‑build application, re‑running the full test suite (another 40 minutes), and getting sign‑off from every team, because any part of the monolith could theoretically be affected. Total time: roughly half a day, plus risk to unrelated features.
After splitting into microservices, the same typo fix touches only notification-service. That service builds in 2 minutes, has its own small test suite, and can be deployed the moment the fix is merged — with zero risk to Payments, Catalog, or Checkout, because those run as completely separate processes. Total time: a few minutes.
Think of a big LEGO castle built as one solid, glued block versus one built from separate LEGO pieces you can snap in and out. If you want to change just the tower’s colour, the glued castle means repainting (and risking) the whole castle. The snap‑together castle means you just pop off the tower, repaint that one piece, and snap it back — the rest of the castle never even notices.
“The main advantage of microservices over a monolith is that each service can be independently developed, deployed, and scaled. This means teams can release changes faster with lower risk, failures are isolated to one service instead of crashing the whole system, and you can scale only the parts of the system under heavy load — instead of scaling everything together, which wastes resources.”
Full Advantages, Disadvantages & Trade‑Offs
No architecture is free of cost. A great engineer understands trade‑offs, not just benefits. Let us cover both sides honestly.
Microservices — Advantages
- Independent deployability (the main advantage, covered in Chapter 7).
- Fault isolation: one service crashing does not take down the whole app.
- Independent, targeted scalability: scale only the busy services.
- Technology diversity: each team can pick the best language / database for their job (polyglot persistence / programming).
- Team autonomy: small “two‑pizza teams” (a term Amazon made famous — a team small enough to be fed by two pizzas) can own a service end‑to‑end.
- Faster, safer releases: smaller, more frequent deployments reduce risk per release.
- Easier to understand per‑service: one service’s codebase is small enough for a new engineer to learn quickly.
Microservices — Disadvantages
- Operational complexity: instead of managing 1 application, you now manage 50, each needing monitoring, logging, deployment pipelines, and on‑call rotations.
- Network unreliability: calls between services can be slow, can time out, or can fail — problems a monolith’s in‑memory calls never had.
- Data consistency challenges: no more single‑database transactions across the whole flow; you need patterns like Sagas and must design for eventual consistency.
- Distributed debugging is harder: a single user request might touch 8 services — you need distributed tracing to see the whole picture.
- Higher infrastructure cost at small scale: running many small services (each with overhead) can cost more than one efficient monolith, especially for small applications.
- Testing is harder: integration tests need multiple services running together, which is more complex than testing one process.
- Requires strong DevOps maturity: you generally need containers, orchestration (like Kubernetes), CI/CD pipelines, and observability tooling to do microservices well.
Monoliths — Real Advantages
- Simplicity: one codebase, one build, one deployment — easy to reason about, especially for small teams.
- Easier transactions: a single database means real ACID transactions across all features, with no eventual‑consistency headaches.
- Lower operational overhead: no need for service discovery, API gateways, or message brokers just to get started.
- Faster to build initially: for early‑stage startups, a monolith usually gets you to market faster.
- Easier debugging: a single stack trace shows you the whole story, since everything runs in one process.
Monoliths — Disadvantages
- Large blast radius: one bug can crash the entire application.
- Scaling waste: you must scale the whole app even if only one feature is under load.
- Slower releases as the team grows: more people means more coordination, merge conflicts, and longer test / build cycles.
- Technology lock‑in: the whole app is stuck with one language / framework choice.
- Onboarding gets harder: new engineers must understand a huge, tangled codebase before contributing safely.
Small, early‑stage, tightly related
Small team (under ~10‑15 engineers) · early‑stage startup validating product‑market fit · simple domain with few, tightly related features · low traffic and no urgent scaling needs.
Big, autonomous, varied load
Large organisation with many independent teams · different parts of the system have very different scaling needs · you need to release different features on different schedules · a strong DevOps / platform team already exists to manage the complexity.
Many companies have publicly shared stories of splitting into microservices too early and suffering — more operational pain than benefit — because their team was small and their traffic did not yet require it. A well‑known real‑world example is Amazon’s own “Prime Video” team, which in 2023 published an account of moving one specific monitoring tool from a microservices / serverless design back to a monolith, cutting their infrastructure cost by about 90% for that particular workload. This does not mean “microservices are bad” — it means microservices solve a specific problem (team scale and independent deployability), and applying them where that problem does not exist adds cost without benefit.
Performance & Scalability
Scalability is a system’s ability to handle more load (more users, more requests, more data) by adding more resources. There are two classic ways to scale.
Monoliths can scale horizontally too (running many copies of the whole app behind a load balancer), but every copy carries all features — even the ones under no load. Microservices allow fine‑grained horizontal scaling: you can run 30 copies of the Catalog Service and just 2 copies of the Notification Service, matching resources to actual demand.
Load balancing
What it is: A component that spreads incoming requests across multiple identical server instances so no single instance gets overwhelmed. Analogy: a theme park staff member directing new visitors to whichever ticket booth has the shortest line. Common algorithms: Round Robin (take turns), Least Connections (send to whoever is least busy), and Weighted (send more traffic to stronger machines).
Latency vs Throughput
Latency is how long one single request takes (e.g., 120 milliseconds). Throughput is how many requests the system can handle per second (e.g., 5,000 requests / second). Microservices can slightly increase latency per request (because of extra network hops between services), but they can dramatically increase overall throughput because each bottlenecked part can be scaled on its own.
Caching
What it is: Storing a copy of frequently‑requested data somewhere fast (usually in memory) so future requests do not need to redo expensive work. Analogy: a teacher who memorises the answer to a commonly‑asked question instead of looking it up in a textbook every single time. Example: a Catalog Service caches its 100 most‑viewed products in Redis (an in‑memory data store), so 95% of product‑view requests never even touch the database.
High Availability & Reliability
Availability means the percentage of time a system is up and working correctly. It is often described in “nines” — e.g., “three nines” (99.9%) means about 8.7 hours of downtime per year; “five nines” (99.999%) means about 5 minutes per year.
Fault isolation, revisited
In a monolith, if the Payment module has an unhandled error that crashes the process (say, an out‑of‑memory error), the entire application goes down — Login, Catalog, everything. In microservices, if the Payment Service crashes, users can still browse the Catalog and even add items to a Cart; only checkout is affected, and even that might gracefully degrade (e.g., “Payments temporarily unavailable, please try again shortly”) instead of a total outage.
Circuit Breaker Pattern
What it is: A safety mechanism that “trips” (stops sending requests) to a struggling service after it fails repeatedly, giving it time to recover instead of hammering it with more requests that will also fail.
A home electrical circuit breaker. If too much current flows (a short circuit), the breaker trips and cuts power, preventing a fire — instead of letting the wires keep overheating.
Java example — Circuit Breaker with Resilience4j
// Explanation: this defines a circuit breaker that "opens" (stops calling)
// the Payment Service if 50% of the last 10 calls failed, and waits
// 5 seconds before trying again.
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50)
.slidingWindowSize(10)
.waitDurationInOpenState(Duration.ofSeconds(5))
.build();
CircuitBreaker circuitBreaker = CircuitBreaker.of("paymentService", config);
Supplier<String> decoratedCall = CircuitBreaker
.decorateSupplier(circuitBreaker, () -> paymentClient.charge(orderId));
String result = Try.ofSupplier(decoratedCall)
.recover(throwable -> "Payment temporarily unavailable, please retry")
.get();Retry & Timeout patterns
A timeout gives up waiting for a response after a set time, instead of waiting forever. A retry tries the request again (often with a growing delay between attempts, called “exponential backoff”) in case the failure was temporary — like a brief network hiccup.
Redundancy & Replication
Redundancy means running multiple copies of something so that if one fails, others keep working. Replication specifically means keeping copies of the same data on multiple machines, so losing one machine does not lose the data. Analogy: keeping copies of an important family photo on your phone, a laptop, and in the cloud. Losing one device does not lose the photo.
Disaster Recovery & Backups
Production systems regularly back up databases and test “failover” — the process of switching traffic to a backup region or data center if the main one goes down. Companies define a Recovery Time Objective (RTO) — how long it is acceptable to be down — and a Recovery Point Objective (RPO) — how much recent data it is acceptable to lose, in the worst case.
Security
Security in microservices is different (and in some ways harder) than in a monolith, because there is now a network between components that an attacker could try to intercept.
Key concepts
Who you are
Proving who you are (e.g., logging in with a password). Analogy: showing your ID at the door.
What you can do
Proving what you are allowed to do (e.g., only admins can delete products). Analogy: your ID badge only opens certain doors, not all of them.
A signed wristband
A JSON Web Token: a small, signed piece of data that proves a user is authenticated, passed along with each request so services do not need to re‑check a password every time. Analogy: a wristband at a theme park that proves you already paid, so you do not need to show your ticket at every ride.
Both sides show ID
Both sides of a service‑to‑service connection prove their identity to each other using certificates, encrypting the traffic. Analogy: two people showing ID badges to each other before starting a private conversation.
One central door
API Gateway as a security checkpoint centralises authentication so individual services do not each have to reinvent it.
Never hardcode
Services need passwords, API keys, and certificates. Instead of hardcoding these in source code (a common and dangerous mistake), production systems use tools like HashiCorp Vault or cloud‑native secret managers (AWS Secrets Manager, Azure Key Vault) to store and rotate secrets safely.
Zero Trust principle
In modern microservices security, the rule is: never automatically trust a request just because it came from “inside” the network. Every service verifies every incoming request, even from other internal services. This is called Zero Trust — the opposite of the old idea that “anything inside our firewall is safe.”
Attack surface trade‑off
A monolith has one “front door” to secure. Microservices have many services, many APIs, and many network paths — a larger attack surface (the total number of ways an attacker could try to get in). This is one honest downside of microservices: more moving parts to secure carefully.
Monitoring, Logging & Metrics
When one user request travels through 6 different services, and something goes wrong, how do you find out which service caused the problem? This is one of the hardest operational challenges microservices introduce — and it is solved with three pillars of “observability.”
The Three Pillars of Observability
Text records of what happened
Text records of events that happened inside a service (“User 42 logged in,” “Payment failed: card declined”). Challenge in microservices: logs are scattered across dozens of services and machines. The solution is centralised logging — shipping all logs to one searchable place. Tools: the ELK stack (Elasticsearch, Logstash, Kibana), or Splunk.
The dashboard numbers
Numbers tracked over time — requests per second, error rate, average response time, CPU usage. Like a car’s dashboard: speed, fuel level, engine temperature — quick numeric signals of health. Tools: Prometheus (collects metrics) + Grafana (visualises them as dashboards).
Follow one request’s journey
Follow one single request as it hops across multiple services, recording how long each hop took. Without tracing, if a checkout takes 3 seconds, you have no idea whether the slowness came from Payment, Shipping, or the database. Like a tracking number for a package showing every warehouse it passed through. Tools: Jaeger, Zipkin, OpenTelemetry.
Health Checks
Each microservice typically exposes a small /health endpoint that says “I’m alive and working” or “I’m unhealthy.” Orchestration systems (like Kubernetes) call this endpoint regularly and automatically restart or stop sending traffic to unhealthy instances — without a human needing to notice first.
Deployment & Cloud
Modern deployment tooling — containers, orchestration, and CI/CD pipelines — is what makes running many independent services feasible at all.
Containers
What it is: A lightweight, self‑contained package that bundles an application together with everything it needs to run (code, libraries, settings), so it behaves the same way on any machine. Why it exists: to solve the classic “it works on my machine” problem. Analogy: a shipping container — no matter what is inside (furniture, electronics, food), it has the same standard shape, so any ship, train, or truck can carry it. Example tool: Docker.
Container Orchestration
What it is: A system that automatically starts, stops, restarts, and scales containers across many machines, based on rules you define. Analogy: an airport’s flight control tower — deciding which gate each plane uses, rerouting planes if one gate breaks, and making sure there are always enough planes running each route. Example tool: Kubernetes (often called “K8s”).
CI/CD (Continuous Integration / Continuous Deployment)
What it is: An automated pipeline that builds, tests, and deploys code every time a developer submits a change, instead of doing these steps manually. Why it matters for microservices: with dozens of services, each needs its own independent pipeline — this is exactly what enables the “main advantage” of independent deployability discussed earlier.
Deployment strategies
Cost optimisation
Cloud costs scale with usage. Microservices allow auto‑scaling — automatically adding / removing server instances based on real‑time demand — so you pay for only what you actually use, rather than provisioning for peak load 24/7. However, running many small services also has fixed overhead per service (monitoring agents, small idle base loads), so cost efficiency depends on scale and traffic patterns — this is exactly the trade‑off Amazon’s Prime Video team encountered, mentioned earlier.
Databases, Caching & Load Balancing
Once services own their own data, an old friend — the single, safe database transaction — goes away. This chapter shows what replaces it, and how load is balanced in either architecture.
Database per Service
A core microservices rule: each service owns its own database, and no other service is allowed to query it directly. Other services must go through the owning service’s API. Why: this preserves independent deployability. If services shared one database, changing a table’s structure could silently break five other services — recreating the exact coupling microservices are meant to remove.
Polyglot Persistence
What it is: Using different types of databases for different services, based on what fits each job best.
| Type | Good for | Examples |
|---|---|---|
| Relational | Structured data with relationships, like Orders and Customers | PostgreSQL, MySQL |
| Document | Flexible, tree‑shaped data, like Product Catalogs with varying attributes | MongoDB |
| Key‑Value | Extremely fast simple lookups, great for caching and session data | Redis, DynamoDB |
| Graph | Highly connected data, like a social network’s “friends of friends” | Neo4j |
Partitioning (Sharding)
What it is: Splitting one large database’s data across multiple machines, where each machine holds only a portion (a “shard”) of the total data — for example, users A‑M on one server and N‑Z on another. Why it exists: a single database server has limits on how much data and traffic it can handle. Sharding lets you scale storage and query load beyond what one machine could manage. Analogy: a library so big it is split across two buildings — fiction in Building A, non‑fiction in Building B — so no single building gets overcrowded.
Replication
What it is: Keeping multiple copies of the same data on different machines (unlike sharding, which splits different data across machines). Two common modes:
- Leader‑follower (primary‑replica): one “leader” database accepts all writes, and “followers” copy the leader’s changes, mainly serving read requests, spreading out read load.
- Multi‑leader / leaderless: multiple nodes can accept writes, offering higher availability but requiring more complex conflict resolution.
Caching layers
Microservices commonly use a layered caching strategy:
- In‑memory local cache inside the service itself (fastest, but limited to one instance).
- Distributed cache like Redis or Memcached, shared across all instances of a service.
- CDN (Content Delivery Network) caching static assets (images, videos, scripts) at servers physically close to users around the world.
Load Balancing revisited: client‑side vs server‑side
Server‑side load balancing: a dedicated load balancer sits between the client and the service instances, deciding where to route each request. Client‑side load balancing: the calling service itself gets a list of available instances (from the service registry) and picks one directly, skipping an extra network hop.
APIs & Service Communication
How exactly do microservices “talk” to each other? There are several common styles.
REST (Representational State Transfer)
What it is: An API style using standard HTTP methods (GET, POST, PUT, DELETE) and URLs to represent actions on resources (like /orders/123). Why it is popular: simple, human‑readable, and uses infrastructure the entire internet already understands (HTTP).
Java example — a simple REST endpoint (Spring Boot)
@RestController
@RequestMapping("/orders")
public class OrderController {
private final OrderService orderService;
public OrderController(OrderService orderService) {
this.orderService = orderService;
}
// Explanation: handles GET /orders/{id}
// Fetches order details by ID and returns them as JSON.
@GetMapping("/{id}")
public ResponseEntity<OrderDto> getOrder(@PathVariable Long id) {
OrderDto order = orderService.findById(id);
return ResponseEntity.ok(order);
}
// Explanation: handles POST /orders
// Creates a new order and calls the Payment Service internally.
@PostMapping
public ResponseEntity<OrderDto> createOrder(@RequestBody CreateOrderRequest request) {
OrderDto created = orderService.placeOrder(request);
return ResponseEntity.status(HttpStatus.CREATED).body(created);
}
}gRPC
What it is: A high‑performance communication framework using a compact binary format instead of plain text, ideal for fast service‑to‑service calls. Analogy: REST is like writing a full, readable letter every time; gRPC is like using a dense, pre‑agreed shorthand code between two people who both know it — faster to send, but you need the “codebook” (a schema) beforehand.
Asynchronous messaging (Kafka, RabbitMQ)
Instead of directly calling another service and waiting, a service publishes an event to a topic / queue, and any interested service subscribes and reacts whenever it is ready. This is the backbone of event‑driven architecture, which reduces direct coupling between services even further than REST calls do.
API Versioning
Because services deploy independently, Service A might be updated while Service B (still calling the old API) has not caught up yet. Good practice is to version APIs (e.g., /v1/orders, /v2/orders) and support old versions for a transition period, so independent deployment does not break existing consumers.
Design Patterns & Anti‑Patterns
A handful of patterns show up over and over in mature microservices systems — and an equally recognisable handful of anti‑patterns show up in the ones that struggle.
Essential Design Patterns
Saga Pattern
What it is: A way to manage a business transaction that spans multiple services (which cannot share one database transaction) by breaking it into a sequence of local transactions, each with a matching “undo” step (called a compensating action) if something later fails.
Example: Placing an order involves: (1) reserve inventory, (2) charge payment, (3) schedule shipping. If step 2 fails, a compensating action releases the inventory reserved in step 1 — undoing what was already done, rather than relying on one big rollback.
Booking a vacation with separate flight, hotel, and car rental bookings. If the hotel booking fails after you have already booked the flight, you cancel the flight — an explicit “undo,” since there is no single company that can roll back all three bookings together.
Strangler Fig Pattern
What it is: A strategy for gradually migrating a monolith to microservices by building new features as separate services and slowly routing old monolith functionality to new services piece by piece, until the monolith is fully replaced. Why the name: named after the strangler fig plant, which grows around a host tree, gradually replacing it. Why it matters: rewriting a whole monolith at once (“big bang rewrite”) is extremely risky. The strangler fig approach reduces that risk by migrating gradually, with the system working correctly at every step.
Backend for Frontend (BFF)
What it is: Creating a separate, tailored API layer for each type of client (mobile app, web app, third‑party partner), each shaped to that client’s specific needs, instead of one generic API for everyone.
Sidecar Pattern
What it is: Attaching a helper process (like a logging agent or a service‑mesh proxy) alongside a service, without embedding that logic directly in the service’s own code. Analogy: a sidecar attached to a motorcycle — it rides along and helps, without being welded into the motorcycle’s own frame.
Common Anti‑Patterns (mistakes to avoid)
Distributed Monolith
Splitting code into many services, but keeping them so tightly coupled (shared databases, synchronous call chains, forced simultaneous deployments) that you get all the complexity of microservices with none of the independent‑deployability benefit.
Nano‑services
Splitting services so small (a service with one tiny function) that the network overhead and operational cost vastly outweigh any benefit.
Shared Database
Multiple services directly reading / writing the same database tables, secretly recreating tight coupling.
Chatty Services
A single user action triggering dozens of synchronous cross‑service calls, creating slow, fragile chains — sometimes called a “call chain” problem.
No API Versioning
Changing an API in a way that breaks other services that have not updated yet — a shortcut that quietly poisons independent deployability.
Advanced Topics — CAP, Consensus, Concurrency
A short tour of the deeper distributed‑systems ideas that microservices force teams to reckon with.
CAP Theorem
What it is: A rule stating that in any distributed system that experiences a network failure (a “partition”), you can only guarantee two out of three properties at once:
- Consistency (C): every read gets the most recent write, everywhere.
- Availability (A): every request gets a (non‑error) response, even during failures.
- Partition tolerance (P): the system keeps working even if network communication between nodes breaks down.
Since network partitions will happen eventually in any real distributed system, partition tolerance is essentially mandatory — so the real, practical choice is between Consistency and Availability during a partition.
Two cashiers in different store branches, connected by a phone line that occasionally goes dead. If the phone line drops mid‑partition, you must choose: either stop serving customers until the phone line is fixed (favouring Consistency), or keep serving customers with possibly outdated stock information (favouring Availability).
Practical example: Banking systems often favour consistency (better to briefly refuse a transaction than to show the wrong balance). Social media “like” counts often favour availability (better to show a slightly outdated count than an error page).
Consensus Algorithms
What it is: Algorithms that let multiple machines agree on a single value or decision, even if some machines fail or messages get delayed — critical for things like electing a “leader” node. Examples: Paxos (the original, famously hard to fully understand) and Raft (designed later specifically to be easier to understand and implement, now widely used in tools like etcd, which Kubernetes itself relies on). Analogy: a group of friends trying to agree on one restaurant over a group chat with a spotty signal — a consensus algorithm is the “voting protocol” that ensures they still land on one agreed answer even if a few messages get lost.
Concurrency
What it is: Multiple tasks making progress during overlapping time periods — in software, this often means handling many requests “at the same time.” Why it matters for microservices: each service instance typically handles many concurrent requests. Java, for example, uses threads (independent sequences of execution within one process) to handle multiple requests simultaneously, and modern Java (since Java 21) introduced virtual threads — extremely lightweight threads that let a service handle huge numbers of concurrent requests without exhausting system resources, which is especially valuable for services that spend a lot of time waiting on network calls to other microservices.
Java example — handling concurrent calls with virtual threads
// Explanation: each incoming order request spawns a lightweight virtual
// thread. Because virtual threads are cheap, a service can handle
// thousands of concurrent, network-call-heavy requests efficiently.
try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
for (Order order : incomingOrders) {
executor.submit(() -> {
paymentClient.charge(order); // network call to Payment Service
shippingClient.schedule(order); // network call to Shipping Service
});
}
} // executor auto-closes and waits for all tasks to finishIdempotency
What it is: A property where performing the same operation multiple times has the same effect as doing it once. Why it matters: networks are unreliable — a client might retry a “charge payment” request because it did not get a response in time, even though the first attempt actually succeeded. Idempotent APIs (often using a unique “idempotency key” per request) prevent the customer from being charged twice.
Backpressure
What it is: A mechanism where an overloaded service tells upstream callers to slow down, instead of silently accepting more work than it can handle and collapsing. Analogy: a crowded restaurant putting up a “wait list” instead of letting everyone rush in and overwhelm the kitchen.
Best Practices & Common Mistakes
A handful of durable habits separate the teams that stay productive in microservices from the ones that quietly grind to a halt.
Best Practices
Design around business capabilities, not technical layers
A service should be “Order Management,” not “Database Access Layer.”
Automate everything
Testing, building, deploying — manual steps do not scale to dozens of services.
Invest in observability early
Centralised logs, metrics, and tracing are not optional extras once you have more than a handful of services.
Design for failure
Assume any network call can fail, and use timeouts, retries, and circuit breakers deliberately.
Keep each service’s database private
Never let another service reach directly into your tables, no matter how convenient it feels in the moment.
Version your APIs
Version APIs from day one, even if you think you will never need it — it is much harder to add later.
Start with a modular monolith if you are small
Split into microservices only when a real, felt pain (team scale, deployment bottlenecks) justifies the added operational cost.
Common Mistakes
- Splitting too early — adopting microservices before the team or traffic actually needs it, paying operational cost for no real benefit.
- Splitting along the wrong boundaries — creating services that constantly need to call each other for basic operations, instead of aligning with true bounded contexts.
- Sharing a database “just this once” — this single shortcut quietly recreates monolith‑style coupling and is very hard to undo later.
- Ignoring observability until something breaks in production — by then, diagnosing a distributed failure without tracing is extremely painful.
- Underestimating organisational change — microservices require teams to take on real ownership (including being “on‑call” for their service), which is a cultural shift, not just a technical one.
A famous observation: “Organisations design systems that mirror their own communication structure.” In practice, this means your microservice boundaries usually end up matching your team boundaries — so deciding how to split your teams is just as important as deciding how to split your code.
Real‑World & Industry Examples
The stories below are the ones that get referenced again and again in architecture conversations — and, importantly, one honest counter‑example.
Chaos Monkey and 700+ services
After a major database corruption incident in 2008 that caused a three‑day outage, Netflix began migrating from a monolith to a cloud‑based microservices architecture on AWS. Today, Netflix runs hundreds of microservices, uses Eureka for service discovery, and pioneered “chaos engineering” — deliberately injecting failures (their tool is famously named “Chaos Monkey”) into production to make sure the system’s fault isolation actually works as designed.
The service‑interface mandate
Amazon’s retail platform moved from a large monolith to a service‑oriented architecture in the early 2000s, famously mandating (via an internal memo attributed to Jeff Bezos) that all teams must expose their functionality through service interfaces — no direct internal data sharing. This forced independent deployability across the whole company and is often cited as a foundational moment for the modern microservices movement.
Thousands of services worldwide
Uber started as a monolithic application but, as it expanded into hundreds of cities with rapidly growing engineering teams, split into thousands of microservices to let city‑specific and feature‑specific teams ship independently. Uber has also publicly discussed the resulting operational complexity, investing heavily in internal tooling to manage service discovery, deployment, and observability at that scale.
Squads own their services
Spotify popularised the idea of organising autonomous teams (“squads”) each owning their own microservices end‑to‑end, directly reflecting Conway’s Law — team structure and service structure evolved together.
In 2023, Amazon’s Prime Video team published a case study describing how they redesigned one specific video‑monitoring tool from a distributed, serverless microservices approach into a single monolithic process, reducing cost by roughly 90% for that specific, high‑volume workload. This is a valuable, honest reminder that microservices are a tool suited to specific problems (team scale, independent deployability needs) — not a universal upgrade for every workload.
FAQ, Summary & Key Takeaways
A handful of questions come up almost every time this topic is introduced. Short, honest answers first, then a summary and the takeaways worth keeping.
Frequently Asked Questions
Is microservices always better than a monolith?
No. Microservices trade simplicity for independent deployability and scalability. For small teams and simple applications, a monolith is often faster to build and cheaper to run.
How big should a microservice be?
There is no fixed number of lines of code. The right size is: “small enough to be owned and understood by one small team, and aligned with one clear business capability (bounded context).”
Do I need Kubernetes to do microservices?
Not strictly, but at real scale, some form of container orchestration is nearly universal because manually managing dozens of independently deployed services is impractical.
What is the difference between microservices and SOA?
Both split systems into services, but SOA traditionally used heavier standards and a centralised “Enterprise Service Bus,” while microservices favour lightweight protocols (REST, gRPC, simple messaging) and fully independent deployment per service, without a centralised integration layer.
What is a “modular monolith”?
A middle‑ground approach: one deployable application, but internally organised into clearly separated modules with well‑defined boundaries (similar discipline to microservices), making it easier to split into real microservices later if needed — without paying the full operational cost upfront.
Summary
We started with a simple story: one giant shop versus a mall of small, independent shops. That story captures the entire microservices idea. A monolith bundles every feature into one deployable unit — simple at first, but increasingly rigid as teams and features grow. Microservices break that bundle apart into small, independently deployable services, each owning one business capability and its own data.
The main advantage of microservices is independent deployability and scalability — every other benefit (fault isolation, technology freedom, team autonomy, faster releases) flows directly from that one root property. But this advantage comes with real costs: operational complexity, network unreliability, harder data consistency, and the need for mature DevOps practices (containers, orchestration, observability, CI/CD).
Key Takeaways
Remember This
- Monolith = one deployable unit. Microservices = many independently deployable units, each owning one job and one database.
- The main advantage of microservices is independent deployment and scaling — not “it is newer” or “it is what big companies use.”
- Fault isolation, technology freedom, and faster releases are all downstream consequences of independent deployability.
- Microservices trade simplicity for flexibility — they introduce network unreliability, eventual consistency, and operational overhead.
- Patterns like Saga, Circuit Breaker, API Gateway, and Strangler Fig exist specifically to manage the challenges microservices introduce.
- The CAP theorem forces a choice between Consistency and Availability whenever a network partition occurs — there is no way around it.
- Choose your architecture based on your team size, your traffic patterns, and your organisation’s actual pain points — not based on trends.
At the end of the day, the microservices‑versus‑monolith question is not really a question about code. It is a question about people, priorities, and pain: which set of problems is your team best equipped to live with right now, and which set is quietly costing you more than the other. Both architectures are legitimate long‑term homes for real software, and the teams that consistently pick the right one are the teams that ask that people‑and‑pain question honestly, without letting fashion answer it for them.