Why Monolithic Architecture Still Works—and When It Fails

Background

When developing server‑side enterprise applications, the system must support various client types—desktop browsers, mobile browsers, and native mobile apps—expose APIs to third parties, and integrate with other systems via web services or message brokers. Requests are processed by executing business logic, accessing databases, exchanging information with other systems, and returning HTML/JSON/XML responses.

The application typically follows a multi‑layer or hexagonal architecture composed of several component types:

Presentation components – handle HTTP requests and respond with HTML or JSON/XML (for web service APIs).

Business logic – the core domain functionality.

Database access logic – data access objects for persisting data.

Integration logic – messaging layers such as Spring Integration.

Each logical component serves different functional modules within the application.

Problem

What deployment architecture should the application use?

Requirements

The application must be owned by a dedicated development team.

New team members need to onboard quickly.

The application should be easy to understand and modify.

Continuous deployment must be supported.

Multiple instances must run on different machines to satisfy scalability and availability.

New technologies (frameworks, programming languages, etc.) should be usable.

Solution

Build the application as a monolithic system. Examples:

A single Java WAR file.

A single Rails or Node.js code directory hierarchy.

Example

Consider an e‑commerce application that receives customer orders, validates inventory and credit limits, and then ships products. The system includes several components: StoreFrontUI for the user interface, and backend services for credit checking, inventory management, and order dispatch.

The application is deployed as a single unit—for instance, a Java web app packaged as a WAR running in Tomcat, or a Rails app deployed via Phusion Passenger on Apache/Nginx or JRuby on Tomcat. To improve scalability and availability, multiple instances can be placed behind a load balancer.

Result

This solution offers several advantages:

Easy development – modern IDEs and tools are designed for monolithic apps.

Easy deployment – simply deploy the WAR or directory to the appropriate runtime.

Easy scaling – run multiple copies behind a load balancer.

However, as the application grows and the team expands, the drawbacks become more pronounced:

The massive codebase can intimidate new developers, making the system hard to understand and modify, slowing development, eroding modular boundaries, and degrading code quality.

IDE overload – larger codebases slow down the IDE, reducing productivity.

Web container overload – larger apps increase container startup time, impacting developer efficiency and deployment.

Continuous deployment difficulty – updating a single component requires redeploying the entire monolith, causing unnecessary downtime and increasing risk.

Scaling limitations – monoliths only support one‑dimensional scaling; while you can add more instances, each must handle all data, leading to inefficient caching, higher memory and I/O usage, and inability to scale components independently.

Challenges for large‑scale development – as the system reaches a certain size, teams must split into functional groups (UI, accounting, inventory, etc.), but the monolith forces coordination for changes and deployments, making product updates cumbersome.

Technology lock‑in – the monolith ties the team to the initial technology stack, hindering adoption of newer languages or frameworks and potentially requiring a full rewrite to migrate.

Related Pattern

Microservice architecture is an alternative that addresses many monolithic limitations.

Known Cases

Many well‑known internet services originally started with monolithic architectures, including Netflix, Amazon.com, and eBay. The author’s own web applications also began as monoliths.