Monolith vs Microservices

What it is

Two ends of an architectural spectrum. A monolith packages all functionality into a single deployable artifact sharing one process and (usually) one database. Microservices decompose the system into independently deployable services, each owning its data and communicating over the network (REST, gRPC, or async messaging).

The problem it solves

The real problem isn't technical; it's organizational scaling. A monolith is the right default: one repo, one deploy, in-process calls, easy transactions. It only becomes painful when dozens of engineers contend over the same codebase and deploy pipeline, or when one component needs to scale independently. Microservices let teams own and ship pieces autonomously, at the cost of turning every in-process call into a network call.

How it works

Monolith: modules call each other as function calls; one ACID database; one CI/CD pipeline; scale by running more copies of the whole thing behind a load balancer. Microservices: each service has its own datastore and API; calls cross the network; you need service discovery, an API gateway, distributed tracing, and a strategy for cross-service consistency (sagas, eventual consistency). The migration path is usually 'modular monolith → extract the seams that hurt', not a big-bang rewrite.

Why use it

• Monolith: trivial local dev, in-process calls, real ACID transactions, one thing to deploy and debug
• Microservices: teams deploy independently without coordinating; failures are isolated to one service
• Microservices: scale and choose tech per service, since the video encoder and the auth service have nothing in common

What it costs you

• Microservices turn function calls into network calls: latency, retries, partial failure, and serialization everywhere
• Distributed transactions across services are genuinely hard (you need sagas, not BEGIN/COMMIT)
• Operational overhead explodes: service discovery, tracing, per-service CI/CD, versioned contracts
• Monolith: one bad deploy or memory leak takes the whole app down; scaling is all-or-nothing

Where it shows up in our architectures

• Netflix →

  The canonical microservices shop, with hundreds of services behind Zuul, each owned by a team and independently deployed

• URL Shortener →

  Starts as a near-monolith; only the read and write paths get split because they scale so differently

• Uber →

  Dispatch, geo-index, trips, and payments are separate services so the matching tier can scale independently of billing

Gotchas

• Don't start with microservices. Start with a modular monolith and extract services only where you feel real pain; premature decomposition is the most expensive mistake here.
• Microservices don't make your system simpler. They trade code complexity for operational and network complexity. You need tracing, service discovery, and saga-style consistency before they pay off.
• Service boundaries should follow business domains (DDD bounded contexts), not technical layers. A 'database service' and a 'logic service' is a distributed monolith, the worst of both worlds.
• A distributed monolith (services that must deploy together) gives you all the costs of microservices with none of the benefits. If two services always ship together, they're one service.