Monolith vs Microservices
One big app vs many small ones
Monolithic and microservices architectures represent two approaches to structuring applications. A monolith is a single, unified codebase where all components run together, while microservices split functionality into independently deployable services that communicate over a network.
Monolith
A monolithic architecture packages all application functionality — user interface, business logic, data access, background jobs — into a single deployable unit. All code lives in one repository, shares one database, and runs in one process. Monoliths are simple to develop, test, deploy, and debug because everything is in one place. Many successful companies (Shopify, Stack Overflow, Basecamp) run on monoliths at massive scale. Modern monoliths can be well-structured internally using modules, layers, and clean boundaries without needing network calls between components. The monolith is the default starting point for most applications.
Microservices
A microservices architecture decomposes an application into a collection of loosely coupled, independently deployable services. Each service owns a specific business capability (user service, payment service, notification service), has its own database, and communicates with other services via APIs, message queues, or event streams. Teams can develop, deploy, and scale each service independently using different languages and technologies. However, microservices introduce significant operational complexity: distributed tracing, service discovery, network latency, data consistency across services, and the need for sophisticated CI/CD and monitoring infrastructure.
Key Differences
- **Deployment**: Monoliths deploy as one unit. Microservices deploy independently — update the payment service without touching the user service. - **Data management**: Monoliths typically share one database. Microservices each own their data store (database-per-service pattern). - **Complexity**: Monoliths have in-process complexity. Microservices trade that for distributed-system complexity (network failures, eventual consistency, observability). - **Scaling**: Monoliths scale by replicating the entire application. Microservices allow scaling individual services based on their specific load. - **Team structure**: Monoliths suit smaller teams. Microservices align with Conway's Law — each team owns a service. - **Technology choice**: Monoliths typically use one stack. Microservices allow polyglot technology choices per service.
When to Use Each
**Start with a monolith** for new projects, small teams, and when domain boundaries are unclear. A well-structured monolith is faster to develop, easier to debug, and simpler to operate. Most startups should start here. **Evolve to microservices** when your organization grows (multiple teams stepping on each other), when specific components have drastically different scaling needs, or when independent deployability becomes critical. The extraction should be driven by real pain, not theoretical benefits.
Analogy
**A monolith** is like a Swiss Army knife — every tool is built into one compact unit. It's portable, easy to carry, and you always know where everything is. But if the scissors break, the whole knife goes to the repair shop. **Microservices** are like a professional toolbox with individual tools — a standalone saw, a standalone hammer, a standalone drill. Each can be replaced, upgraded, or loaned out independently, but you need a bigger truck to carry them all and a system to keep track of what goes where.