Overview
A monolith is an application built and deployed as a single unit: one codebase, one build artifact, one process (often scaled as identical copies), and usually one database. All features, such as users, orders, and payments, run in the same process and call each other with in-memory function calls.
Monoliths are the fastest way to build a product: simple to develop, test, debug, and deploy, with transactions and refactoring that are easy. Problems appear as the codebase and team grow: tangled dependencies, slow builds, risky deploys where one bug takes everything down, and the inability to scale parts independently. Many successful companies still run large, well-structured monoliths.
Everything is under one roof with one management and one checkout system. It is easy to run and customers find everything in one place, but renovating one department can disrupt the whole store.
When to use it
- New products and startups searching for product-market fit.
- Small to medium teams (roughly under 20-30 engineers on one product).
- Domains that are not yet well understood.
- Applications with modest scaling needs.
Where it shows up in interviews
Recognize it when: monolith or microservices for this product?
- Design the MVP of a marketplace
- Evolve a startup's architecture
Where it is used in real software
Runs one of the largest Ruby on Rails monoliths, organized into components (a modular monolith), serving millions of merchants.
Serves enormous traffic with a monolithic .NET application on a small number of servers.
Advocates 'the majestic monolith' for productive small teams.
Key terms
- Single deployable
- The whole application ships as one artifact.
- In-process calls
- Modules call each other as functions, not over the network.
- Shared database
- All features use the same schema.
- Big ball of mud
- A monolith with no internal structure.
How it works, step by step
- 1Start with one codebase
Organize by feature folders from day one.
- 2Scale horizontally
Run identical copies behind a load balancer.
- 3Add caching, replicas, and queues
Handle growth without splitting.
- 4Enforce module boundaries
Evolve into a modular monolith.
- 5Extract services only when needed
Where independent scaling or team autonomy justifies it.
Monolith trade-offs over time
How the same architecture feels at different stages
| Stage | Team size | Experience |
|---|---|---|
| MVP | 2-5 | Very fast development, simple deploys |
| Growth | 10-30 | Still productive if modules are clean |
| Scale | 50+ | Merge conflicts, slow CI, risky deploys without strong boundaries |
| Mature | 100+ | Needs modularization or selective extraction |
NOWStage: MVP | Team size: 2-5 | Experience: Very fast development, simple deploys
The monolith is rarely the problem; lack of internal boundaries is.
Implementation
shop-app/ src/ users/ # signup, profiles catalog/ # products, search orders/ # cart, checkout payments/ # charges, refunds shared/ # db, logging, auth middleware migrations/ Dockerfile # one image, one deployment # Checkout calls payments in-process:# const charge = await payments.charge(order.total, card)# One database transaction can cover orders and payments tables.Complexity and performance
Simple pipeline.
Function call.
Trade-offs
Everything scales together; a CPU-heavy feature forces scaling the whole app.
ACID transactions across features are easy, but every change ships with every other change.
Variants and related techniques
Strong internal module boundaries in one deployable.
Services that must deploy together: the costs of both, benefits of neither.
Common mistakes
- Premature microservices.
Fix: Start with a well-structured monolith and extract later.
- No internal boundaries.
Fix: Enforce module APIs and dependency rules.
Interview questions
When is a monolith the right choice?
Early-stage products, small teams, and unclear domains, where development speed, simple operations, and easy refactoring matter more than independent scaling or team autonomy.
How do you scale a monolith?
Run multiple stateless instances behind a load balancer, add caching, read replicas, background queues, and CDNs; then modularize and extract only the parts with distinct scaling or ownership needs.
Practice problems
| Problem | Difficulty | What it trains |
|---|---|---|
| Structure a monolith by feature modules | Easy | Boundaries. |
| Argue monolith vs microservices for a food delivery MVP | Medium | Trade-offs. |