The monolith-versus-microservices discussion is frequently framed in the software industry as a question with a generally correct answer — usually, in more recent years, presented as microservices being the modern, scalable choice and monoliths being the outdated one. This framing obscures a more accurate picture: the two approaches make genuinely different trade-offs, and which set of trade-offs is worth accepting depends heavily on a system's actual scale, team size, and organizational structure, not on which approach is currently more fashionable. A widely cited discussion of the architectural style appears in Martin Fowler's microservices article.
What a monolith actually optimizes for
A monolithic architecture — a single deployable application containing all or most of a system's functionality — optimizes for simplicity of development, deployment, and reasoning about the system as a whole. A developer can typically run the entire system locally, trace a request through the whole codebase without crossing network boundaries, and deploy a single artifact rather than coordinating the deployment of many independent services. For a small team, or a system whose different parts change together frequently, these are genuine, substantial advantages that microservices trade away. For examples of organizations built around distributed work, see read more.
The commonly cited downside — that a monolith inevitably becomes an unmanageable “big ball of mud” as it grows — is real but not inevitable; it's a consequence of insufficient internal modularity (poor cohesion and high coupling, discussed elsewhere on this shelf) within the monolith, not an unavoidable property of the monolithic deployment model itself. A well-modularized monolith, with clear internal boundaries even though everything ships together, avoids much of this problem without paying the operational costs of splitting into separate services.
What microservices actually optimize for
Microservices — splitting a system into multiple independently deployable services, each typically owning its own data and communicating over the network — optimize for independent deployability and independent team ownership. Different teams can deploy their own services on their own schedules without coordinating a shared release, and a service can be scaled, or even rewritten in a different technology, independently of the rest of the system. These are genuine advantages specifically at a scale where a monolith's shared deployment and shared codebase have become the actual bottleneck to a team's ability to ship.
The costs are equally real and often underestimated by teams adopting the pattern before they need it: network calls between services introduce latency and partial-failure modes that don't exist within a single process; data consistency across services, previously guaranteed by a single database transaction, now requires deliberate design; and operationally, a system of many independently deployed services requires considerably more infrastructure, monitoring, and coordination overhead than a single deployable artifact.
- A monolith's common failure mode (unmanageable complexity as it grows) is a modularity problem, not an inherent property of shipping as one deployable unit — it's often fixable without a full split into services.
- Microservices genuinely pay off at a specific pain point: when a shared codebase or shared deployment has become the actual bottleneck for multiple teams shipping independently, not before.
- The operational cost of microservices — network calls, partial failure, distributed data consistency — is real and substantial, and is often underestimated when the decision is made based on scalability concerns the system doesn't have yet.
- It's possible, and often sensible, to start with a well-modularized monolith and extract specific services later, once a genuine, specific need for independent deployability is identified — rather than starting with a full microservices architecture pre-emptively.
Why the framing as a fashion trend causes real harm
Because microservices have been associated in industry discourse with modernity and with well-known, very large companies that use them successfully at their scale, teams sometimes adopt the pattern for organizational or scale reasons they don't actually have, paying the real operational costs of a distributed system without the corresponding benefit that justified those costs for the companies whose blog posts popularized the approach. The trade-off is real in both directions; treating either option as the generally correct modern default, independent of a system's actual size and team structure, tends to produce a worse outcome than a deliberate evaluation of the specific trade-off would have.
Read alongside Conway's Law, discussed elsewhere on this shelf, this decision is really about organizational structure as much as technical architecture — the question of how many independent teams need to deploy independently is often a better starting point than the question of which architecture is currently considered best practice.