Microservices vs. Monolith: Architecture Patterns and Trade-offs

What Each One Actually Is

A monolith is one codebase, one deployable unit, typically one database — the Orders, Users, and Payments logic all live in the same application and can call each other as plain function calls, in the same process, on the same machine.

Microservices split that same functionality into independently deployable services, each with its own database, communicating over the network (HTTP, gRPC, or a message queue) instead of a function call. The service boundary is the important part — it's not just "multiple processes," it's multiple processes that each own their own data and can be deployed, scaled, and changed without coordinating a release with the others.

Neither is "an architecture" in the abstract — both are points on a spectrum, and most real systems that call themselves one or the other are actually somewhere in between (a "monolith" with an extracted search service; "microservices" that still share a database for two tightly coupled ones). The rest of this reference is mostly about the specific, concrete consequences of moving along that spectrum, not a verdict on which end is correct.