Microservices

What are microservices?

Microservices decompose an application into bounded services — each owns a slice of business capability (users, billing, notifications). Services communicate over the network, usually via HTTP APIs or message queues.

Compared to monoliths

Monolith	Microservices
Single codebase and deploy	Many repos or modules, independent deploys
In-process function calls	Network calls with latency and failure modes
Simpler ops early	Requires orchestration, observability, CI/CD maturity

Benefits

• Independent scaling — scale the checkout service during sales without scaling the catalog
• Team autonomy — squads own services end-to-end
• Technology diversity — pick the best language per service (within reason)

Tradeoffs

• Distributed complexity — tracing, retries, idempotency, eventual consistency
• Operational overhead — more pipelines, more dashboards, more on-call surfaces
• Data ownership — each service should own its database; shared DBs create coupling

When the term appears in SaaS

Multi-tenant SaaS products often use microservices internally while presenting a unified UI. Customers rarely “buy microservices” — they buy a product built that way.

Cost reality

Every in-process function call that becomes a network hop buys latency, retries, and serialization overhead — plus the platform to manage it: orchestration, tracing, service discovery, CI per service. Teams underestimate the fixed cost: the same product as a monolith often runs on a third of the infrastructure and a fraction of the on-call load. You pay this tax to scale teams, not code.

What people get wrong

• Splitting before product-market fit. Boundaries drawn before you understand the domain get redrawn expensively over the network.
• The distributed monolith. Services that must deploy together have all the cost and none of the benefit — independent deployability is the entire point.
• One shared database. If every service reads everyone’s tables, you’ve built a monolith with extra steps; data ownership per service is non-negotiable.

See the full decision framework in Microservices vs Monolith.

The Coordination Cost of Splitting a System

While microservices solve real problems around independent scaling and team autonomy, they introduce their own class of challenges that a single monolithic application doesn’t face: network calls between services are slower and less reliable than in-process function calls, distributed transactions across multiple services’ databases are genuinely difficult to implement correctly, and debugging a request that touches a dozen services requires distributed tracing tooling that a monolith simply doesn’t need. This is why microservices are generally recommended as a response to specific organizational or scaling pain points a team has actually encountered — different parts of a system needing to scale independently, or multiple teams needing to deploy independently without blocking each other — rather than adopted preemptively as a default architecture, since the added operational complexity is a real, ongoing cost that needs to be justified by a genuine corresponding benefit.