The Default Approach
A Monolithic Architecture is the simplest way to build software. Your entire application — the user interface, the business rules, the database connections — is built and deployed as a single, unified unit.
Think of it like a single large house where all the rooms (kitchen, bedroom, living room) are connected without interior doors. Everyone shares the same space. It is easy to navigate when you live alone, but chaotic when twenty people move in.
How It Actually Works
A monolith is deployed as one artifact — one Java .jar, one Ruby on Rails app, one compiled .exe, one Docker container. When you start it, everything starts. When it crashes, everything crashes.
All parts of the application share the same process memory and the same database. The "User" code and the "Billing" code can call each other's functions directly, without any network hop. This is fast and simple.
A typical monolith deployment looks like this:
[Load Balancer]
|
[App Server 1] [App Server 2] [App Server 3]
(full app copy) (full app copy) (full app copy)
| | |
+----------------+----------------+
|
[Single Shared Database]
You scale by running more copies of the entire application. You cannot scale just the billing module — you scale everything or nothing.
The Trade-off
Pros: Extremely fast to develop initially. Simple to deploy (one artifact). Easy to test end-to-end because everything runs in one process. Straightforward to debug because there are no network calls between components — a single stack trace tells the whole story.
Cons: As the codebase grows and more developers join, it becomes a "Big Ball of Mud." A change to the billing module requires redeploying the entire application, including the user profile code that had nothing to do with the change. A memory leak in one feature can crash the entire system. Teams block each other because they all work in the same codebase and deploy pipeline.
Interviewers often ask: "When would you choose a monolith over microservices?" The correct answer is not "never." A monolith is the right choice for early-stage products, small teams, and domains where the boundaries between components are not yet well understood. Martin Fowler's "MonolithFirst" pattern argues you should start with a monolith, learn the domain, then extract services once the boundaries become clear. Jumping to microservices before you understand your domain boundaries is one of the most common and costly architectural mistakes.