What are the trade-offs between a monolith and microservices?
Quick Answer
A monolith is one deployable — simple to build, test, deploy and debug; scales as a unit. Microservices are many independently deployable services — independent scaling and deployment, team autonomy, technology choice — at the cost of network calls, distributed transactions, eventual consistency, and heavy operational tooling. Most teams should start with a well-structured monolith.
A monolith is one codebase, one deployable — easy to develop, test and debug, and you deploy and scale it as a whole. Microservices give you independent deployment and scaling, and teams can own their service, but you pay for it: every in-process call becomes a network call that can fail, transactions span services so you need sagas and the outbox pattern, and you need real investment in tracing, service discovery and resilience. My default advice is to start with a well-structured monolith, ideally a modular one with enforced boundaries, and only split out a service when there's a concrete reason — one component needs to scale separately, or two teams keep colliding.
- A modular monolith gets most of the boundary benefits (clear modules, enforced dependencies) without the distributed-systems tax.
- Split to services when you have a real driver: independent scaling of one hot component, teams stepping on each other, different availability requirements.
- Costs: service discovery, resilience (retry/circuit-breaker everywhere), distributed tracing, data ownership, saga/outbox for consistency, more infra.
- Conway's law — your architecture tends to mirror your org structure.