Monolithic Architecture — one deployable unit, one database
Monolithic architecture on an interactive canvas: one deployable application with UI, business logic and data access modules, a shared database, and the scaling ceiling that results.
A monolith is an application built and deployed as one unit: the UI, business logic and data access all run in a single process against a shared database, and scaling means replicating the whole thing.
Monolithic Architecture — one deployable unit, one database
The interactive FlowJam canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
How to read this visual
- Follow the request in from the client, down through the three modules, into the shared database, and back out — one round trip through one process.
- The modules are inside the "Monolithic application" band because they share a process and a deployment; that containment is the definition of a monolith.
- The final box is the punchline: the scaling path is to the side, duplicating the whole application.
The request path through one process
"Client sends a request" enters "Request enters the single deployable application", then "UI module routes and renders", "Business logic module processes it" and "Data access module queries the database" — all inside the one "Monolithic application" lane. The three modules are drawn stacked to show that they share memory, a process and a deployment: nothing about them is separately deployable.
The shared database
"One shared database stores everything" is the monolith's second defining feature. All modules read and write the same schema, which makes joins and transactions straightforward — the reason a monolith is so productive early. The "Database" cluster sits outside the application band because it is a separate process, but it is shared: the coupling lives in the schema every module depends on.
The scaling ceiling
"The response returns through the same modules" completes the round trip, and "Scaling means replicating the whole application" is the verdict. A busy feature forces the entire codebase and its connection pool onto another server, wasting capacity on the parts that are not busy. That inefficiency, not any technical failure, is what eventually motivates the split into microservices.
Key relationships and takeaways
- All modules share one process, one codebase and one deployment — that containment is the definition.
- The shared database couples every module to a single schema.
- Requests travel through every module in one round trip — there is no separate service call.
- Scaling is coarse: the whole application is duplicated, busy feature or not.
- The monolith's speed of development is real; the scaling ceiling is what it trades away.
When to use this visual
- Explaining why a team's application is hard to scale even though it is easy to develop.
- Teaching the contrast that makes microservices understandable — the split only makes sense against the monolith's ceiling.
- Documenting a legacy system's structure before planning how to break it apart.
How it works
Rename the modules to your codebase
Replace UI, business logic and data access with your actual layers and modules, and add the ones the generic three miss.
Mark the real scaling bottlenecks
Annotate the final box with the actual feature or query that forces your scaling, and the capacity wasted by replicating the whole application.
Draw the extraction candidates
Add a dashed boundary around the module that is the best candidate to become a service, with a note on what coupling would have to be cut.
Link to the microservices alternative
Once the extraction candidates are marked, link to the microservices visual to compare the target architecture side by side.
Frequently asked questions
What is a monolithic architecture?
A monolith is an application whose UI, business logic and data access are built, deployed and scaled as one unit — a single codebase producing a single deployable artifact, running against a shared database. The visual shows the request travelling through all three modules inside one application lane, because that containment is the definition.
Why do teams start with a monolith?
Because for most teams and most of an application's life, a monolith is the fastest way to ship. There is no network between modules, the shared schema makes joins and transactions simple, and deployment is one artifact. The visual's shared-database box calls this out directly — the trade only turns negative when independent scaling or team autonomy becomes the binding constraint.
What is the main problem with a monolith?
The scaling ceiling and the coupling. Scaling means replicating the whole application, so one busy feature wastes capacity across everything else, and every change touches a codebase and a schema that everyone depends on. As the team and codebase grow, those two effects slow deployment and force coordination — the conditions under which teams start extracting services.
How does a monolith become microservices?
Gradually, by extracting one capability at a time. The first step is identifying a module that can stand alone — its own bounded data — then giving it its own database, an API, and eventually independent deployment. The visual's extraction candidate step models exactly this: mark the module, cut the coupling, and split. The mistake is rewriting the whole monolith at once, which is how migrations fail.
Edit this visual in QueryChart (FlowJam)
Open this exact monolith canvas as your own chart, rename the modules to your codebase, and map your scaling bottleneck.