Microservices give you independent deployability and fault isolation. They also give you distributed transactions, network latency, and a debugging problem that gets exponentially harder as you add services.
The microservices conversation in most engineering teams goes one direction: from monolith to services, justified by independent scaling, independent deployability, and team autonomy. Rarely does anyone tally the costs added by the split. They are real, they compound as you add services, and understanding them is what separates an architect from an engineer who just draws boxes.
Inside a monolith, a function call takes nanoseconds and never fails due to infrastructure. Across service boundaries, every call is a network request: 1–10ms, and subject to packet loss, timeouts, and the other service being down for deployment. A user action that triggers 6 service calls has a combined failure probability of 1 - (0.999)^6 = 0.6% even if each service has 99.9% availability. Ten services: 1%. With 100ms timeout per call and 6 calls, your p99 latency floor is 600ms before a line of business logic runs. These costs compound invisibly until you measure them.
A monolith with a single database gets ACID transactions for free. Decrement inventory and create an order in one transaction: either both happen or neither does. Across two services with two databases, there is no free transaction. You can use 2PC (blocking, fragile) or sagas (eventually consistent, complex). Both are harder than the database transaction they replace. The most common mistake is splitting a service boundary through a concept that genuinely needs transactional integrity, then discovering this only when you see double-charges or orphaned records in production.
In a monolith, a stack trace tells you everything. In a microservices architecture, a single user request fans out across 8 services. If something goes wrong, the error appears in service 7, but the root cause is in service 2. Without distributed tracing (Jaeger, Zipkin, OpenTelemetry), you're debugging by log-grepping across 8 services and trying to correlate by timestamp. Getting distributed tracing right requires every service to propagate trace context headers, every database call to be instrumented, and a trace collection and query system that stays up even when services are misbehaving. This is a significant engineering investment that the monolith simply didn't need.
A monolith has one artifact to build, one artifact to deploy, one rollback procedure. A 50-service system has 50 independent CI/CD pipelines, 50 versioned APIs that must maintain backwards compatibility while being updated, and a combinatorial explosion of possible version combinations running simultaneously during a rolling deployment. API versioning strategy, contract testing, and service mesh configuration are not optional at this scale. They are survival skills. Teams that skip them accumulate an invisible debt of 'we can't upgrade service X because service Y depends on the old behavior.'
The canonical case for microservices is when different parts of a system have genuinely different scaling requirements, deployment cadences, or team ownership. A payments service that must be audited and deployed by a compliance-aware team. A recommendation engine that runs on GPUs and needs to be retrained and redeployed weekly without touching the product. A public API that needs to be versioned independently from internal services. In these cases the added complexity is load-bearing: it is buying real organizational or operational leverage. The failure mode is splitting services prematurely, before the scaling or team friction is actually felt, and paying all the complexity costs without any of the benefits.