Monolith vs Microservices

The monolith-vs-microservices debate is one of the most important architectural decisions in system design. A monolith packages all functionality into a single deployable unit. Microservices decompose the system into independently deployable services, each owning a bounded context.

Start Monolith, Evolve to Microservices

The industry consensus — echoed by Martin Fowler, Sam Newman, and most experienced architects — is to start with a monolith and extract services as clear domain boundaries emerge. Premature decomposition creates distributed monolith anti-patterns that combine the worst of both worlds.

The Operational Tax

Microservices impose a significant operational tax: service discovery, load balancing, distributed tracing, circuit breakers, container orchestration, and inter-service auth. Organizations that lack mature DevOps practices often struggle more with the infrastructure than the business logic.

Data Management

In a monolith, a single database handles all data with ACID guarantees. Microservices follow the database-per-service pattern, which means you lose cross-service transactions. Patterns like the Saga pattern and CQRS help manage distributed data, but they add complexity.

Team Topology

Conway's Law predicts that system architecture mirrors team structure. Microservices work best when teams are organized around business capabilities — each team owns one or more services end-to-end. A monolith works best when a single team can reason about the entire codebase.

For more on this topic, see our microservices interview questions and system design interview guide. Explore pricing for full access to guided practice.

The Bottom Line

Monoliths are not legacy — they are a valid architecture for many teams and products. Choose microservices when you have the organizational maturity, operational tooling, and clear domain boundaries to justify the complexity.