System Architecture - Monolith¶

Description¶

A monolithic architecture is a system where the entire application is built and deployed as a single unit.

All components, such as the user interface (server side rendering), business logic, and data access layer, are tightly integrated and run in the same codebase and are deployed together as one application.

When to use¶

Early-stage startups
Small to medium systems
Small engineering teams
Well understood and stable domain
Fast time-to-market requirements

If your product is still evolving and you need speed, a monolith is often the best first choice.

Pros¶

Simplicity
- One codebase
- One deployment pipeline
- Easy local development
- Lower cognitive load for the team
Easier testing
- No network calls between services
- Integration tests are straightforward
Better performance (Initially)
- In-memory calls instead of network calls
- No distributed system overhead
Strong consistency
- Single database
- ACID transactions are simple

Cons¶

Scalability Limitations
- You scale the entire application, even if only one module needs more resources
Tight coupling
- Changes in one module can affect others
- Harder to evolve independently
Slower deployment overtime
- Longer build times
- Harder parallel team work
Technology lock-in
- All parts must use the same language and framework

Note

The problems usually are not the monolith itself, but the way it is structured. A well-structured monolith can be maintainable and scalable for a long time. The key is to modularize (Physical vs Logical Monolith) the codebase and enforce clear boundaries between components.

Summary¶

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvin Conway

System architecture tends to reflect team structure. If one team owns everything, a monolith is often natural.

Many successful companies started monolithic, they later decomposed when scaling required it.