Monolith
A software architecture where all components of an application are unified, interdependent, and run as a single process.
Detailed Explanation
A monolithic application has all its code—frontend, backend, database access, business logic—in one codebase and one deployment unit. This is how most applications are built initially because it is simple to develop, test, and deploy. There is no network communication between components; everything calls functions in the same process.
As monoliths grow, they can become harder to maintain: the codebase becomes large, deployments become risky, scaling requires scaling the entire application, and teams get in each other's way. However, many successful companies (Shopify, Basecamp, Stack Overflow) run monoliths effectively. The key is maintaining good modularity within the monolith.
Why It Matters
Monoliths are the starting point for most applications. Understanding when to keep a monolith versus migrating to microservices is a critical architectural decision.
Real-World Example
Stack Overflow runs as a monolith on .NET. Despite serving millions of users, the monolith handles all features—questions, answers, reputation, moderation—in a single application with excellent performance.
When to Use
For most new projects, especially with small teams. A well-structured monolith is simpler to develop, test, and deploy than microservices. Migrate to microservices only when the monolith's limitations become painful.
Advantages
- Simple to develop and debug
- Single deployment unit
- No network communication overhead
- Easy to test end-to-end
- Simpler DevOps requirements
Disadvantages
- Scaling requires scaling the entire application
- Large codebases become hard to navigate
- Deployment risk increases with size
- Teams can step on each other's code
- Technology choices apply to the whole application
Related Terms
Frequently Asked Questions
Should I start with a monolith or microservices?
Start with a monolith. Microservices add complexity that only pays off at scale. Build a well-structured monolith first. Extract services when you have specific reasons (team scaling, different scaling needs).
How do I keep a monolith maintainable?
Use modular architecture (separate concerns into modules), enforce boundaries between modules, maintain good test coverage, keep the codebase clean through refactoring, and document architecture decisions.
When should I migrate from monolith to microservices?
When: deployments become too risky or slow, teams need to work independently, specific parts need different scaling, or the monolith is too large for any one person to understand. Migrate incrementally, not all at once.
What is a modular monolith?
A modular monolith has clear boundaries between components (modules) that communicate through well-defined interfaces, but all run in one process. It gives the simplicity of a monolith with some benefits of modularity.
Can a monolith scale?
Yes. You can scale a monolith horizontally (multiple copies behind a load balancer) and vertically (bigger server). However, microservices let you scale individual components independently, which is more efficient at large scale.