Architecture
Monolith
A single deployable application holding all features in one codebase and process. It is the right default: simple to build, test, deploy and debug, with cheap in-process calls and easy transactions. It strains only at scale — large teams stepping on each other and slow build/deploy times — which is when a modular monolith or a split starts to pay off.
Purpose
A monolith is a single deployable application: all features in one codebase, one process, one database. It is the natural starting shape for software — everything is a cheap in-process call, one transaction can span the whole domain, and there is exactly one thing to build, test, deploy and debug.
When to Use It
It is the right default for new products, small-to-medium teams, and any system whose scale does not force a split — which is most systems. Many very large companies still run successful monoliths; the architecture is not a stage to grow out of by default.
Trade-offs
Strain appears with organisational scale: many teams stepping on one codebase, slow builds and deploys, and one bug taking the whole application down. Everything also scales together — you cannot give just the hot path more machines.
Implementation
Keep it modular: clear internal boundaries by domain (a 'modular monolith'), so modules interact through interfaces rather than reaching into each other's tables. That discipline keeps the codebase healthy and — if a split is ever genuinely needed — the seams already exist.