Monolithic architecture

Pattern · Chapter 8

The idea in brief

A monolithic architecture ships the whole application as a single, self-contained unit.
Concerns (UI, business logic, authorization, logging, data access) are intertwined, not separated, producing tightly coupled code.
Common and perfectly reasonable for small applications; the pain begins as size and complexity grow.

Better performance — inter-machine communication is minimized; calls stay in-process.
Easy to deploy — one simple high-level unit.
Easier to test and debug — fewer separate moving parts to reason about.
Simple to scale horizontally — just run more instances of the whole app.

Coarse-grained scaling — you can only scale the entire app; components with different scaling needs cannot scale independently.
Reduced agility / hard continuous deployment — a change to one component forces redeployment of the whole system, demanding more time and testing.
Falling maintainability — tight coupling means a change in one area is likely to ripple into others.
Onboarding friction — a large codebase is hard for team members (especially new ones) to understand; the IDE and startup times slow down, hurting productivity.
Technology lock-in — commitment to one language/stack; introducing new tech (or even upgrading versions) is hard, and migration means rewriting the whole app.
Team scaling friction — hard to split responsibilities across teams because one team’s changes may affect another’s.

Large, complex systems should move away from the monolith.
Microservice architecture and serverless architecture address many of these limitations — at the cost of added complexity.

Software Architect’s Handbook (Packt, 2018), Ch.8 “Monolithic architecture”, pp. 603-606.