Monolith vs Microservices: which to choose?

A monolith is the right choice for most startups, MVPs, and applications with teams smaller than 15-20 developers. It offers simpler deployment, easier debugging, no network latency between components, and straightforward transaction management. Start with a well-structured monolith (modular monolith pattern) and extract services only when specific scaling bottlenecks or team autonomy needs arise. Premature microservices add distributed systems complexity without proportional benefits.

Yes, and the strangler fig pattern is the proven approach: identify bounded contexts in your monolith, extract them one by one into independent services, and route requests through an API gateway. Start with the component that has the clearest boundaries and the most independent scaling needs (e.g., notification service, payment processing). Each extraction should be invisible to end users. Plan for 6-18 months for a full migration depending on codebase size and team experience with distributed systems.

A monolith typically has lower latency for individual requests because all function calls are in-process with no network overhead. Microservices introduce inter-service communication latency (1-10ms per hop), which compounds in request chains touching multiple services. However, microservices enable independent scaling — you can allocate more resources to bottleneck services without scaling the entire application. For read-heavy workloads, microservices with dedicated caches per service can outperform monoliths by a wide margin.

Microservices have a vast ecosystem of supporting tools: container orchestration (Kubernetes), service mesh (Istio, Linkerd), distributed tracing (Jaeger, Zipkin), API gateways (Kong, Envoy), and service discovery (Consul). Monoliths rely on simpler, more established tools — a web framework, a database, and a deployment script. The microservices tooling ecosystem solves problems that monoliths simply do not have, so a larger ecosystem is not necessarily an advantage unless your architecture creates those problems.

Microservices cost 3-5x more to develop and operate than an equivalent monolith in the early stages. You need infrastructure for service discovery, container orchestration, distributed logging, and inter-service communication — all before writing business logic. Operational costs are higher due to multiple deployments, monitoring dashboards, and the need for DevOps expertise. A monolith can be developed and deployed by a single full-stack developer, while microservices typically require a minimum team of 5-8 engineers including DevOps.