Monolith vs. Microservices
One deployable codebase vs. many independently deployable services.
A monolith is a single application handling all responsibilities, deployed as one unit. Microservices split those responsibilities into separate, independently deployable services that communicate over the network. Microservices solve real problems at scale — independent scaling, independent deployment, team autonomy — but they trade simplicity for operational complexity that most projects don't need on day one.
Monolith
Best for
- New projects and startups where speed of iteration matters most
- Small teams where the coordination overhead of services isn't yet justified
- Applications without wildly different scaling needs across features
Trade-offs
- Scaling means scaling the whole application, even if only one part needs it
- A bug in one part can, in the worst case, affect the whole application's stability
Microservices
Best for
- Large organizations where multiple teams need to deploy independently without blocking each other
- Systems with genuinely different scaling profiles per component (e.g. a heavy video-processing service vs. a lightweight API)
- Organizations that already have the operational maturity (monitoring, CI/CD, service discovery) to support them
Trade-offs
- Network calls between services introduce latency and failure modes a monolith's function calls don't have
- Distributed tracing, service discovery, and cross-service data consistency all become real engineering problems
- Meaningfully higher operational and infrastructure cost
| Dimension | Monolith | Microservices |
|---|---|---|
| Deployment | Single unit | Independent per service |
| Operational complexity | Lower | Higher — needs service discovery, monitoring, orchestration |
| Team scaling | Coordination overhead grows with team size | Teams can own and deploy services independently |
| Best starting point | Almost always, for new projects | Only once a real, felt need exists |
Verdict
"Start with a monolith" is close to a consensus recommendation for new projects — the common failure mode is adopting microservices' complexity before the organizational or scaling need that justifies it actually exists. Split out a service when a specific, concrete pain point (independent scaling, independent deployment cadence) makes it worth the operational cost, not preemptively.