01 · What is it?What is it?
A monolith packages the main application capabilities into one deployable unit.
That unit may contain separate modules such as accounts, catalog, checkout, and reporting. “One application” describes how the system is built and shipped; it does not mean every feature must be in one file or that the code cannot have boundaries.
Important distinction
A monolith is an architecture and deployment choice, not a synonym for “old,” “simple,” or “badly designed.” A well-structured monolith is often a deliberate starting point.
02 · Think of it like...Think of it like...
Think of a department store with one building, one operating schedule, and shared back-office systems.
Inside the building, different departments can still have clear responsibilities. Customers enter through the same place, and a release to the building may affect all departments. A monolith has a similar shape: many capabilities live behind one application boundary and are shipped together.
ONE DEPLOYABLE APPLICATION
↓
Accounts
Catalog
Checkout
Reporting
03 · What does it do?What does it do?
Packages capabilities
It keeps multiple business functions in one application codebase and runtime.
Shares a release
A production deployment normally carries the application as one unit, even when only one module changed.
Enables local coordination
Modules can call each other directly and often share application libraries, transactions, and data access patterns.
User request→↓Monolithic application→↓Database / external systems
04 · Where is it used?Where is it used?
Monoliths are common when a product has one main team, one release train, a cohesive domain, or a need to move quickly before the boundaries are fully understood.
Early-stage products
One deployable unit can reduce infrastructure and coordination while the team validates the product.
Internal tools
A single application is often enough when usage, ownership, and change patterns are relatively contained.
Business platforms
Modular monoliths can support many capabilities while keeping transactions and operations straightforward.
05 · ExampleExample
Imagine an online retailer with one application for browsing products and placing orders.
Customer action
A shopper checks out with three items.
Request — the checkout module validates the cart, reserves inventory, charges payment, and creates the order.
Response — the application returns an order confirmation to the browser.
Product implication
The customer gets one consistent checkout flow and the business can keep the order steps in one transaction.
The trade-off is that a deployment or failure in a neighboring module can affect the whole application, and checkout cannot be scaled completely independently from catalog.
06 · How it connectsHow it connects
A monolith can still use APIs, background jobs, queues, caches, load balancers, and external services. The defining boundary is the main application unit, not the absence of other infrastructure.
Browser / mobile client→↓Monolith API→↓Database→↓Queue / email worker
For example, the application may save an order synchronously and publish an event for email or analytics to process asynchronously.
07 · Do Not ConfuseDo Not Confuse
Monolith ≠ one file
A monolith can have many packages, modules, teams, and layers inside one deployable application.
Monolith ≠ no boundaries
Good internal interfaces and ownership boundaries still matter; they make future change safer.
Monolith ≠ legacy
A new product can intentionally start as a monolith, and a mature product can remain one successfully.
Monolith ≠ cannot scale
A monolith can scale horizontally by running multiple copies behind a load balancer, although all modules scale together.
Modular monolith ≠ microservices
Both can have clear modules, but microservices are independently deployable and operated processes.
Monolith ≠ shared database only
Sharing a database may happen in several architectures; deployment and runtime boundaries are the key distinction here.
08 · Topic GlossaryTopic Glossary
| ENGLISH TERM | 中文 | SIMPLE ENGLISH | 中文小白理解 |
|---|
| Monolith | 单体应用 | An application whose major features are built and deployed together. | 主要功能放在一起开发和部署的应用。 |
| Deployable Unit | 可部署单元 | The unit that is released to a runtime environment. | 一次发布到运行环境中的整体。 |
| Module | 模块 | A part of an application organized around a responsibility. | 围绕一项职责组织起来的应用部分。 |
| Modular Monolith | 模块化单体 | A monolith with deliberate internal boundaries between modules. | 虽然一起部署，但内部模块边界清楚的单体应用。 |
| Blast Radius | 影响范围 | How much of a system can be affected by one failure or change. | 一次故障或改动可能影响到系统多大范围。 |
| Independent Deployment | 独立部署 | Releasing one service without releasing the others. | 只发布一个服务，不必同时发布其他服务。 |
09 · What to RememberWhat to Remember
A monolith is one main application and deployment unit containing multiple capabilities. It can be a fast, economical choice when the domain and team are still forming.
PM PerspectiveAsk what the product actually needs before choosing distributed services: How often must one capability scale independently? How many teams need separate release cadence? What failure isolation is worth the added operational cost? A modular monolith can preserve speed now while creating boundaries that make a later split possible if the evidence supports it.