Before microservices took over the conference circuit, virtually every serious application was built one way. As a single, unified thing.
That way now has a slightly derisive name: the monolith. And here’s the funny part. Its reputation is far better among people who operate software than among people who give talks about it.
📌 TL;DR: Monolithic architecture = one application, one codebase, one deployment, usually one database. It's simple to build, test, and reason about. Harder to scale selectively, and easy to tangle as it grows. For data teams, a mixed gift: everything's in one database, designed for the app, not for you.
What Is Monolithic Architecture?
Monolithic architecture is a software design where an application is built and deployed as a single unified unit. One codebase, one deployment, one shared database. All the features live together (ordering, billing, user management), so they ship as one thing and scale as one thing.
The honest trade-offs
- Simplicity wins early: one thing to build, test, deploy, and debug. Small teams move fast in monoliths
- Consistency comes free: one database means transactions just work. None of the distributed-data agony
- Scaling is all-or-nothing: you scale the whole application even when one feature is the bottleneck
- Coupling accumulates: without discipline, everything touches everything, and changes grow frightening
- One failure, one blast radius: a memory leak anywhere can take down everything
Notice the shape of that list. The strengths belong to early life. And the weaknesses arrive with age and scale.
What monoliths mean for data work
A monolith’s single database is the canonical source for everything the application knows. Convenient to find. But it’s modeled for the app’s needs, not analytical ones. And it’s often guarded by teams rightly nervous about extra load.
So the standard answer is extraction. You replicate or pipeline the data out to analytical systems instead of querying production.
Aging monoliths shade into legacy-system territory. And the modern fashion of splitting them into services is half the reason data integration became a growth industry. The monolith’s data didn’t disappear. It scattered.
The monolith-to-microservices arc, and its correction
The industry ran a decade-long experiment worth learning from. Act one: monoliths everywhere, growing tangled as teams grew. Act two: the microservices wave. Decompose everything, deploy independently, scale selectively.
Act three was quieter. The correction. Teams discovered that distributing a system distributes its complexity too. Network failures between what used to be function calls. Data consistency across what used to be one transaction. And operational overhead multiplied by service count.
So a mature position emerged: the “modular monolith.” One deployable with strictly enforced internal boundaries. It serves most teams better than either extreme. Modules can extract into services LATER, when a specific scaling or team boundary demands it. You earn the complexity instead of prepaying it. Architecture becomes a series of reversible decisions, not one grand bet.
And the deciding variable, consistently, is team topology rather than technology. Services earn their overhead when independent teams need independent deploy cadence. A five-person team running twelve services is wearing a large company’s costume, and paying its dry-cleaning bill.
The database at the center of it all
For data work, the monolith’s defining feature is its single shared database. One schema holding everything the application knows.
The blessings are real. Transactions work across all business objects. There’s one place to look. And referential integrity gets enforced by the engine itself.
So are the curses. The schema serves application needs: normalized, write-optimized, with cryptic column names from 2011. Analytical queries compete with production traffic. And the tables become a de facto public API that every report quietly depends on. Which makes schema evolution a diplomacy problem.
The standard resolution is extraction. You replicate the monolith’s data outward, change-data-capture into a warehouse via pipelines, so analytics gets fresh data without touching production. And the application team regains schema freedom behind a maintained contract. When monoliths DO decompose, that same extraction layer becomes the safety net. It keeps reporting whole while tables migrate out from under it.
Judging a monolith honestly
- Deploy friction: if releases need coordination meetings, the monolith is taxing velocity. If they ship daily, it isn’t broken
- Blast-radius history: how many incidents took everything down vs one feature? That answer prices the isolation microservices would buy
- Scaling shape: is load uniform (monolith-friendly) or concentrated in one hot path (a candidate for extraction)?
- Team boundaries: are teams blocked on each other’s merges? The org chart is whispering about architecture
- Data coupling: could a module take its tables and leave? If no module could, boundaries exist only in diagrams
A checklist before any decomposition
- Name the pressure: which concrete pain (scaling, deploy speed, team collision) is the split solving? “Modern architecture” is not a pressure
- Extract the data plan first: which tables leave with the service, and how do yesterday’s joins become tomorrow’s contracts? The database split IS the project
- Price the operations: each new service brings deployment, monitoring, on-call, and versioning overhead. Multiply honestly
- Keep a reversible first step: extract ONE candidate behind an interface and run it for a quarter before believing the roadmap
Answer these four in writing and one of two good things happens. You proceed with clear eyes. Or you discover the modular monolith was the destination all along. Both outcomes beat guessing.
Real-World Examples
You’ve used monoliths all week, whether you noticed or not. Here’s where the model shows up in real life.
A ten-person startup runs its whole product as one deployable on one database. They ship five times a day. No service mesh, no coordination meetings. At their size that’s the right call, not a compromise.
A mid-size retailer runs a fifteen-year-old commerce monolith. The analytics team replicates its database into a warehouse nightly, because production queries are forbidden. That’s the classic extraction pattern in action.
And several famously large engineering teams still run deliberately monolithic codebases at serious scale, with strict internal modules and heavy tooling. So the lesson isn’t that monoliths don’t scale. It’s that discipline scales, with or without decomposition.
Common Mistakes
The monolith conversation attracts predictable errors. These five cost the most:
- Splitting for fashion. Decomposing without a named pressure trades one tangle for a distributed one, plus a pager bill
- Ignoring the database split. Teams decompose the code and leave one shared database underneath. That’s a distributed monolith, the worst of both worlds
- Letting boundaries rot. A monolith without internal modules becomes the tangled ball its critics describe. Boundary discipline is cheap early and brutal late
- Reporting off production. Analytics load on the app database slows customers and angers the app team. Extract instead
- Misreading the org chart. Five people running twelve services, or five teams sharing one deploy queue. Both are architecture mismatched to team shape
Frequently Asked Questions
What is monolithic architecture in simple terms?
Building an application as one unified unit: single codebase, single deployment, usually a single shared database. Everything ships together and scales together.
Is monolithic architecture bad?
No. It’s the right choice more often than conference talks admit: simpler to build, test, and operate, especially for small teams and early products. It becomes a problem when scale or team size demands independent parts.
What is the difference between monolithic and microservices architecture?
A monolith is one deployable unit; microservices split the application into independent services that communicate over networks. The trade is simplicity versus selective scaling, plus distributed data complexity.
What is a modular monolith?
A single deployable application with strictly enforced internal module boundaries: monolith operations, service-like discipline. It captures most of microservices’ organizational benefits while deferring their distributed-systems costs until specifically justified.
When should a monolith be split?
When a concrete pressure demands it: a component needing independent scaling, a team needing independent deployment, or a boundary needing different technology. Split at the seam that hurts, extract one service, and re-evaluate. Big-bang decompositions trade one tangle for a distributed one.
Do monoliths scale?
Further than their reputation suggests: vertical scaling plus replicas carries single deployables to serious traffic, and many large products still run this way. The real ceiling is usually organizational (deploy collisions between teams) before it’s technical.