In software (Private), a monolith is a single-tiered application where the UI and data access code is combined into a single program. Monoliths are self-contained, independent from other applications.

Monoliths can follow modular design patterns:

  • Code modularity lets developers split the source tree into a series of modules, some of which may expose interfaces allowing extension.
  • Object modularity allows reusing parts of the application or deploying them independently (shared objects; dynamic link libraries) or distributing them across multiple systems (Microsoft COM+).

The term has roots in mainframe applications.

When to use it


  • Quicker to develop initially, especially with a smaller team.
  • Easy to continue growing an existing codebase to meet new feature requirements.
  • Reduced release engineering and operational complexity.
  • "Don't repeat yourself" drives reuse.
  • Easier to replicate the environment, as there's just one large component.


  • Large solutions/IDE projects, leading to longer build times.
  • Too many people involved in decision making.
    • Highly-coupled shared components make it difficult to move quickly.
  • All actions have unintended consequences.
  • Data storage systems like databases become rigid due to shared dependencies.
  • Sets technology stack in stone, preventing adoption of better-suited tools.