Application Architecture
Monolith, modular monolith, microservices: what each solves, what each costs, and the decision between them.
A monolith is one deployable process containing every business capability — auth, users, orders, payments, notifications — sharing one database and one transaction scope; it is the cheapest architecture to build, run and debug, scales further than its reputation suggests, and is not automatically bad.
A modular monolith keeps one deployable and one database but enforces service-grade boundaries inside it — each module exposes a public API, owns its tables, and communicates through in-process events — so teams get independence in the codebase without paying for a network, and a module can later be extracted along a boundary that already exists.
Microservices split an application into independently deployed services that each own their data and talk over the network — buying team autonomy, independent releases and per-service scaling at the price of partial failure, lost transactions, contract versioning and an observability stack; adopt them for a measured organisational or scaling problem, or you build a distributed monolith.