Monolith
MON-oh-lith
A single, unified application where all code runs in one process and deploys as one unit.
A monolith is an application where all the code lives in a single codebase, runs in a single process, and deploys as a single unit. The user interface, business logic, and data access are all part of one application. This is the simplest architecture and the default starting point for most software.
Monoliths have a bad reputation because of failed attempts to scale them. But for most startups and small teams, a monolith is the right choice. It is simpler to develop, test, deploy, and debug than a distributed system. Function calls are faster than network calls. Database transactions are simpler than distributed transactions.
The monolith becomes a problem when the team outgrows it: when deployment coordination across teams is painful, when one team's change breaks another team's code, or when different parts of the application need different scaling characteristics. That is when decomposition into services makes sense.
Examples
A startup builds a monolith.
A 4-person startup builds their entire application as a single Rails app. Authentication, billing, API, and admin dashboard all live in one codebase. One deploy ships everything. One database stores everything. The team moves fast because there is zero operational overhead.
A monolith hits scaling limits.
The monolith now has 500,000 lines of code, 30 engineers, and a 45-minute build time. A change to the checkout flow accidentally breaks the search feature because they share utility functions. The team decides to extract the search service first, then payments, keeping the rest as a monolith.
A 'modular monolith' gives the best of both.
Instead of splitting into microservices, the team organizes the monolith into strict modules (payments, search, users) with clear boundaries and no shared database tables between modules. Each module can eventually become a service, but for now they share a deployment and avoid distributed system complexity.
In practice
Read more on the blog
Frequently asked questions
Is a monolith bad?
No. A monolith is the right architecture for most teams, especially early-stage. Shopify, one of the largest e-commerce platforms, runs a modular monolith. The question is not monolith vs. microservices but whether your current pain points justify the complexity of distribution.
When should you break up a monolith?
When team coordination costs outweigh the simplicity benefits. Specific signals: deployment requires scheduling across teams, build times exceed 15 minutes, changes frequently break unrelated features, and different parts need different scaling characteristics.
Related terms
An architecture where an application is built as a collection of small, independent services.
A single repository that contains multiple projects, packages, or services managed together.
The accumulated cost of shortcuts and deferred work in a codebase that slows future development.
Restructuring existing code without changing its external behavior to improve readability and maintainability.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.