Monolithic Architecture
An architectural pattern where all components of an application are bundled into a single unit.
Detailed Explanation
Monoliths are easier to build, test, and deploy initially because everything is in one codebase. However, as the application grows, the monolith becomes harder to maintain, slower to build, and difficult to scale. A change in one small part requires redeploying the entire application. Many large systems start as monoliths and are later broken into microservices.
Quick Summary
A monolith is a single deployable application, one codebase, one process, one release. It's the simplest architecture, the default starting point, and (with proper modular design) the right answer for most products well past their first million users.
Key Takeaways
- One codebase, one build, one deploy, refactors are cheap and atomic.
- Inter-module calls are in-process function calls, not network hops; no distributed-systems failure modes.
- A monolith is not the opposite of "good architecture", a modular monolith with clear internal boundaries is often the best of both worlds.
- Scaling is typically vertical, but a monolith can be scaled horizontally behind a load balancer once the database supports it.
- Failure modes are simpler: one process up or down, not a partial outage of three services.
When to use it
- Early-stage startups and small teams where shipping speed matters more than scale.
- Internal tools and admin panels with predictable load.
- Products where the domain is not yet stable enough to draw service boundaries.
- Acquihired projects being absorbed into an existing system.
Common Mistakes
- Treating "monolith" as a slur and over-engineering to microservices before it's needed.
- Letting the monolith become a big ball of mud, without internal modules, refactoring later is hellish.
- Sharing global mutable state across modules so they can never be cleanly separated.
- Deploy times that grow until every change feels expensive, invest in faster builds before the team revolts.
Monolithic Architecture, Frequently Asked
Is monolith vs. microservices a binary choice?
No. The modular monolith, one deploy, clear internal module boundaries, is a common middle ground. Many systems also split off a few microservices for specific high-load or independent components while the core stays monolithic.
When should I break up the monolith?
When team-coordination friction or scaling pressure on one specific module justifies the operational complexity. "It feels old-fashioned" is not a reason. Shopify, GitHub, and Basecamp run very large monoliths successfully.
Can a monolith scale to millions of users?
Yes. Stack Overflow famously serves billions of requests/month from a small monolithic .NET app on a handful of machines. Database design and caching matter more than service decomposition for raw throughput.