Monolith

A monolith is an application whose code is built, deployed, and scaled as a single unit. The user interface, business logic, and data-access layers live in one codebase and run in one process (or a small set of identical processes behind a load balancer).

How It Works

All modules call each other through in-process function calls rather than network requests. A single build produces one artifact, and a single deployment ships every change. The application typically connects to one shared database. To scale, operators run more copies of the entire application behind a load balancer, even if only one feature is under load.

Why It Matters

Monoliths are simple to develop, test, and deploy early in a project's life. In-process calls are fast and easy to reason about, transactions span the whole system naturally, and there is no network partitioning to handle. For small teams and clear domains, a well-structured monolith ships faster than a distributed system.

The trade-offs appear at scale. A large codebase becomes hard to change safely, every deployment risks the whole system, and teams contend over a shared build and release pipeline. Scaling is coarse: you cannot independently scale a hot component. These pressures often motivate a move toward a modular monolith or microservices, but that move adds operational complexity and should be driven by real constraints rather than fashion.

Related Terms

A modular monolith keeps a single deployment while enforcing internal module boundaries. Microservices split the application into independently deployable services. SOA is an earlier service-oriented style.