Monolith
Software architecture where all functionality is in a single, cohesive codebase and one shared deployment artefact.
The monolith is the oldest and still most widespread architecture pattern in software development. Despite the microservices hype, a monolithic architecture is the right choice for many companies, especially in the early phase of a project. Knowing its strengths and limits and recognising the right time for migration is what matters.
What is Monolith?
A monolith is a software architecture where all functionality of an application is combined in one codebase. Frontend, backend, business logic and database access are developed, compiled and deployed as one unit. Typical examples are classic Java EE applications, WordPress installations or Ruby on Rails apps. A well-structured monolith uses modules or layers (layered architecture) for internal order but is still deployed as a single artefact. The so-called modular monolith aims to combine the simplicity of a monolith with the structure of microservices.
How does Monolith work?
All components of a monolith run in the same process and share the same memory. Function calls between modules happen directly in memory, which is very fast and reliable. A single database stores all data, making consistent transactions trivial (ACID). For deployment, the whole application is rolled out as one unit. Changes to one module therefore require a full build and redeployment of the entire system.
Practical Examples
WordPress: One of the most successful monolithic applications, powering over 40% of all websites worldwide. PHP code, templates and database in one unit.
Mid-size e-commerce shop: Shop frontend, product management, inventory and customer management in one Django or Laravel application.
Internal company portal: Employee directory, leave requests, time tracking and document management as a monolithic Java Spring application.
Startup MVP: A first version of a SaaS product built as a monolith to get to market quickly and gather feedback.
Typical Use Cases
Startups and MVPs: Fast development and simple deployment when speed matters more than scalability
Small teams (2–8 developers): Less infrastructure overhead and simpler coordination than with microservices
Simple domains: Applications with manageable complexity that do not require independent scaling of parts
Prototypes: Quick validation of business ideas without the overhead of distributed systems
Internal tools: In-house applications with predictable load and limited user base
Advantages and Disadvantages
Advantages
- Simplicity: One codebase, one deployment, one log, one debugging process
- Performance: Direct in-memory calls instead of network communication between services
- Consistency: ACID transactions across all data without distributed transaction patterns
- Lower operational effort: No Kubernetes, no service mesh, no distributed tracing infrastructure
- Quick start: Fewer architecture decisions and tooling setup for new projects
Disadvantages
- Scaling limits: The whole application must be scaled even when only one part is under load
- Deployment risk: Every change requires a full redeploy with potential outage
- Growing complexity: Build times and risk of spaghetti code increase with codebase size
- Team bottlenecks: Large teams block each other when changing the same codebase
Frequently Asked Questions about Monolith
Is a monolith bad?
When should you move from monolith to microservices?
What is a modular monolith?
Related Terms
Want to use Monolith in your project?
We are happy to advise you on Monolith and find the optimal solution for your requirements. Benefit from our experience across over 200 projects.