Monolith

One Application as a Single Unit

In a monolith, the main parts of the product live in one application and usually share one lifecycle: they are built, tested, and deployed together. Inside there may be controllers, business logic, data access, and dozens of functional areas, but from the outside it is one running component.

Client -> Monolith -> Database
          |-- users
          |-- orders
          |-- payments

This does not mean the code must be mixed into one pile. A monolith can have clean packages, modules, and dependencies. It is defined primarily by a single deployment boundary, not by the absence of internal structure.

Why a Monolith Is Convenient at the Start

One process is easier to run locally, test, and observe. Calls between application parts are regular local calls, and data changes can often be performed in one transaction. The team does not need to solve network failures, inter-service compatibility, and coordination of multiple deployments from day one.

While the product and team are not too large, this simplicity is often more valuable than independently scaling every function. A change that touches several parts of the system can be implemented and released as one coordinated update.

Where Limitations Begin to Appear

As the application grows, the shared deployment boundary becomes more restrictive. A small change requires rebuilding and releasing the whole product, different teams touch the same code more often, and the entire process must be scaled even when load grows only for one function.