Monolith Architecture
A monolith architecture packages all application functionality — presentation, business logic, and data access — into a single deployable unit that runs as one process.
A monolith architecture packages all application functionality — presentation, business logic, and data access — into a single deployable unit that runs as one process.
What the diagram shows
The diagram illustrates a classic three-tier monolith. All client requests arrive at a Load Balancer, which distributes traffic across multiple identical instances of the Monolith Application. Within each instance, traffic flows through four internal layers: the Presentation Layer handles HTTP routing and view rendering; the Business Logic Layer contains domain models, validation, and service orchestration; the Data Access Layer encapsulates queries and ORM mappings; and finally all reads and writes hit a single shared Relational Database.
A Cache (Redis or Memcached) sits beside the data access layer to absorb repeated reads, reducing database pressure for hot data such as user sessions and product listings.
Why this matters
Monoliths are not inherently wrong — they are often the right starting point. A single deployable artifact means simpler local development, fewer network round-trips between components, and straightforward ACID transactions across the entire domain. Many successful products run on well-structured monoliths for years.
The difficulty surfaces at scale: deploying a change to one layer requires redeploying the entire application, and a memory leak in one module can crash all functionality at once. These pressures motivate the move toward Microservice Architecture once team size and traffic volume justify the added complexity. For scaling a monolith before that migration, see Scalable Web Architecture.