Benefits and Drawbacks of Microservices

Simple to develop. One IDE project, one build, no service-to-service contracts to design up front; an IDE’s full toolchain (refactoring, debugging, "find usages") works across the whole codebase at once.

Easy to make radical changes. Moving a field from Order to a new Shipment entity, or renaming a package, is a single, atomic, compiler-checked commit — there is no second service whose contract might break.

Simple to test and deploy. One test suite exercises the whole application in one run; one build produces one artifact (bookshop.jar) that is deployed as a single unit, with no cross-service version matrix to reason about.

Easy X-axis scaling. Per the scale cube, cloning the whole monolith behind a load balancer is enough for a long time — there is nothing microservices-specific needed to handle Bookshop’s early traffic growth.

Complexity intimidates developers. bookshop.jar has grown from a handful of packages to dozens; a developer joining the Payments team still has to understand enough of Catalogue and Shipping to be confident a change will not break them, because everything shares one process and one compilation unit.

The edit-build-run-test loop slows down. A full rebuild and startup of bookshop.jar now takes minutes instead of seconds, and the test suite — still one suite for the whole application — takes long enough that developers stop running it locally before every commit.

The path from commit to production gets longer. What used to be same-day deploys becomes a monthly release train: every change, however small, has to wait for a full regression pass of manual testing across every capability, because no one can be sure a Catalogue change did not somehow affect Payments.

Conflicting resource requirements make scaling hard. Catalogue’s full-text search index is memory-hungry; Payments' authorization calls are CPU-light but latency-sensitive and must never be starved. Because both run inside the same bookshop.jar process on the same instance type, there is no way to give Catalogue more memory without also over-provisioning memory nobody needs for Payments, or to isolate Payments from a garbage-collection pause triggered by Catalogue’s indexing load.

No fault isolation. A memory leak in Catalogue’s search indexing eventually takes down the whole bookshop.jar process — Payments and Checkout go down with it, even though nothing about them was ever broken.

Locked into an increasingly obsolete stack. Adopting a new library, framework version, or even a new JVM version means testing and migrating the entire application at once; the cost of that all-or-nothing upgrade means Bookshop’s team keeps deferring it, and the gap to current tooling keeps widening.

Continuous delivery and deployment. Once bookshop-catalogue is its own service, its team can ship a search-ranking fix the same day it is written, without waiting for — or risking — Bookshop’s monthly release train.

Small, easily maintained services. bookshop-payments alone is small enough for a new engineer to understand end to end in a day, unlike the sprawling bookshop.jar it was extracted from.

Independent deployability. bookshop-orders can deploy ten times a day while bookshop-shipping deploys once a week, each on its own schedule, without either one blocking the other.

Independent scalability. bookshop-catalogue is scaled for CPU and memory (more, bigger instances for its search index); bookshop-payments is scaled for reliability (multiple availability zones, aggressive health checks) rather than raw throughput — exactly the conflicting requirements the monolith could not satisfy at the same time.

Autonomous, "two-pizza" teams. A single small team can own bookshop-shipping end to end — its code, its database, its on-call rotation, its release calendar — without needing sign-off from every other team touching bookshop.jar.

Easy experimentation with new technology. Bookshop’s Recommendations service (born outside the monolith from day one, per the "stop digging" strategy in Migration Path: From a Monolith to Microservices) can be written in Kotlin to try a new stack, without risking the stability of the rest of the system the way rewriting a chunk of bookshop.jar in a new language would.

Fault isolation. A memory leak inside bookshop-catalogue now crashes only bookshop-catalogue; bookshop-payments keeps authorizing charges normally while Catalogue’s pods restart.

Finding the right set of services is hard, and it is easy to get wrong in either direction: too coarse and the benefits above barely materialize; too fine and the services barely communicate without excessive chatter. Getting the boundaries wrong in a way that leaves services tightly coupled produces exactly the distributed monolith anti-pattern — all of the network overhead, none of the independent deployability.

Distributed systems are inherently more complex. A method call inside bookshop.jar becomes inter-process communication (IPC) over the network once bookshop-orders calls bookshop-payments: it can now fail partially, arrive late, or arrive twice, so bookshop-orders needs retries, timeouts, and a circuit breaker around that call where an in-process method call needed none of them (see Resilience Fundamentals).

Loss of ACID transactionality. A checkout that used to be one local database transaction across Order, Payment, and Shipment rows now spans three separate services and three separate databases; there is no single commit that covers all of them. Why Distributed Transactions Don’t Work Across Microservices explains why two-phase commit is not the answer, Sagas shows how Bookshop instead sequences local transactions with compensations under eventual consistency, and CQRS covers how a query that used to be a single SQL join across Order and Catalogue tables becomes API composition or a dedicated read model once those tables live in different services' databases.

Higher complexity and much more code and infrastructure to maintain, per service, that a monolith never needed at all:

Coordinated cross-service feature rollouts. A feature that touches both Orders and Payments now needs its two halves released in a compatible order (or behind a feature flag) instead of landing in one atomic commit.

A higher operational and skills bar. Running five services well needs container orchestration, service mesh or gateway operational knowledge, and distributed-tracing literacy that a single-JAR monolith never demanded of the team.

Deciding when to adopt microservices is itself hard. The inconveniences above are real costs paid starting on day one, while the benefits mostly compound later, as the team and codebase grow — which is exactly the timing question Choosing: Monolith or Microservices? takes on next.

Martin Fowler — Microservice Trade-Offs

microservices.io — Pattern: Microservice Architecture

Google Cloud Architecture Center — Microservices Architecture on Google Cloud