Monolithic Architecture
Monoliths are treated as the thing to escape from, but they're often the right choice. Understanding their real strengths and weaknesses (not the hype) is a senior skill.
The Concept Explained
A monolith is an application deployed as a single unit. All the code ships together, runs in one process, and typically shares one database.
The word has acquired a pejorative sense that gets in the way of thinking clearly, so it is worth being precise about what a monolith actually is and is not. A monolith is not necessarily badly structured. It can have clean module boundaries, well-defined interfaces, and strict internal layering. What makes it a monolith is that it deploys as one unit, not that its code is tangled.
That distinction matters because the two properties are independent. A well-modularized monolith is a perfectly respectable architecture. A tangled mess split across forty services is not improved by the split; it is a distributed tangled mess with network calls between the tangles.
Monolith describes the deployment unit, not the code quality. The genuine tradeoffs of a monolith come from everything shipping and running together: one process, one database, one release. Confusing "monolith" with "badly organized" is what leads teams to adopt microservices as a code-quality strategy, which it is not.
How It Works
The Advantages People Overlook
This is the substance of the interview question, and the answers are more concrete than the usual "it is simpler."
Calls are function calls. An in-process call costs on the order of nanoseconds. A round trip to another service in the same datacenter costs on the order of half a millisecond. That is roughly a fifty thousand times difference. A monolith performs operations that a distributed system cannot afford, and any decomposition converts some function calls into network calls at that exchange rate.
Transactions actually work. One database means a real ACID transaction across everything the operation touches. Reserve inventory, charge the customer, create the order: commit or roll back, atomically, with no compensating logic. The Distributed Transactions material in the sibling course exists entirely because this stops being true once you split.
Refactoring across boundaries is cheap. Moving a responsibility between modules in a monolith is a code change the compiler checks. Moving it between services is a migration involving two deployments, an API version, and a period where both exist. Early in a product's life, when boundaries are still wrong, this matters enormously.
Debugging is a single stack trace. One process, one log stream, one profiler. Reproducing a bug means running the application. In a distributed system the equivalent requires correlated traces across services, and the tooling to make that work is itself a project.
Operational surface is one thing. One deployment pipeline, one monitoring configuration, one runtime to patch. A team of five running one application is doing something very different from the same five running forty services.
What Changes When One Unit Becomes Many
Monolith
One deployment unit
Microservices
Many deployment units
Where the Limits Actually Bite
Monoliths do have real limits, and being precise about which ones you are hitting is what makes the decision to split defensible.
Deployment coupling, which is usually the first to hurt. Everything ships together, so a risky change in one area blocks releases everywhere, and one team's failing test holds up everyone. This is an organizational constraint rather than a technical one, and it scales with the number of people rather than the amount of traffic.
Uniform scaling. You scale the whole application, so a component needing ten times the capacity forces you to run ten times everything. Wasteful, though usually cheaper than people assume compared with the engineering cost of splitting.
Blast radius. One process means a memory leak, an unbounded query, or a crash in any part can take down the whole application.
Technology lock-in. One runtime for everything. A workload better suited to a different language cannot easily have one.
Build and test times. Past a certain size, the feedback loop degrades until it changes how people work, and that is a genuine productivity cost.
Notice that most of these limits scale with team size rather than traffic. A monolith serving very high traffic with a small team is usually fine. A monolith of moderate traffic with two hundred engineers contending over one release pipeline is painful. Teams frequently cite scaling when the actual pain is deployment coupling, and that misdiagnosis leads to splitting along technical lines when the fix was to split along team lines.
System Design Implications
Start with a monolith unless you have a specific reason not to. For a new product the boundaries are unknown, and getting them wrong inside a monolith costs a refactor while getting them wrong across services costs a migration. The advice to begin monolithic and extract later is not conservatism, it is deferring an irreversible decision until you have the information to make it.
Modularize from the beginning even though you are not splitting. Clear internal boundaries, explicit interfaces between modules, and a rule that modules do not reach into each other's tables. This costs little early and it is what makes a later extraction feasible. A monolith with real internal boundaries is often called a modular monolith, and it captures most of the organizational benefit of services without the distribution cost.
Split for reasons you can name. A component with genuinely different scaling characteristics, a team that needs an independent release cadence, a workload requiring a different runtime, or a blast-radius problem you cannot solve in-process. Each is a specific justification. "Microservices are best practice" is not.
Extract one service at a time, from the edges inward. The strangler fig pattern later in this course is the mechanism. Extracting the component with the fewest dependencies first gives you a working distributed system to learn on before you attempt anything central.
Keep the database boundary in mind above all others. Splitting services while they continue to share tables gives you distributed complexity with none of the independence, since the shared schema still couples every deploy. If services share a database, they are one system wearing several hostnames.
The strongest version of this answer names the specific advantages rather than saying "simplicity." In-process calls at nanoseconds against network calls at half a millisecond, real ACID transactions instead of sagas, one stack trace instead of distributed tracing, and boundary refactors the compiler checks. Then add the diagnostic: most monolith pain scales with team size rather than traffic, so establish which one you are actually feeling.
Tradeoffs and Decision Framework
| Signal | Points toward monolith | Points toward splitting |
|---|---|---|
| Team size | Small, one release train works | Large, release contention is real |
| Domain boundaries | Still uncertain | Stable and well understood |
| Scaling profile | Uniform across features | One component dominates |
| Transactional needs | Operations span many entities | Naturally partitioned |
| Operational maturity | Limited, few engineers | Strong platform capability |
| Runtime needs | One language suits everything | A workload needs something else |
| Deploy frequency | Coordinated releases are fine | Teams blocked by each other |
The framework in three steps. First, name the specific pain, and be honest about whether it is deployment coordination, scaling cost, blast radius, or build times, because those have different fixes and only some require splitting. Second, check whether the pain is solvable inside the monolith, since modularization, a faster build, or a read replica may address it at a fraction of the cost. Third, if splitting is warranted, extract the single component that would most relieve the pain rather than embarking on a full decomposition.
The default should be that the burden of proof sits with splitting. A distributed system is strictly harder to build, operate, and debug, and that cost is permanent while the benefit is specific.
Common Mistakes
Equating monolith with badly written. Deployment unit and code quality are independent, and conflating them leads to adopting microservices as a code-quality strategy.
Splitting before boundaries are understood. A wrong boundary inside a monolith is a refactor; across services it is a migration with API versioning and a dual-running period.
Citing scaling when the pain is deployment coupling. Different diagnosis, different fix. Release contention is an organizational problem that splitting along team lines addresses and splitting along technical lines does not.
Splitting services while sharing a database. Distributed complexity with none of the independence, since the shared schema recouples every deploy.
Underestimating what transactions were doing for you. The moment you split, every cross-service operation needs a saga with compensation, and that is a substantial permanent cost.
Never modularizing. A monolith without internal boundaries is genuinely hard to extract from later, which is what makes the eventual migration expensive.
Big-bang decomposition. Rewriting into services all at once is the highest-risk version of the project. Extract incrementally from the edges.
When is a monolithic architecture the right choice over microservices? What are the real advantages people overlook?