Monolithic Architecture: One Deployable Unit

A monolith is an application built from one codebase and deployed as one unit: every feature, from sign-in to checkout, runs in the same process and ships in the same release. Parts call each other as ordinary functions, and usually share one database. Most products start this way, and many large ones stay this way on purpose.

What it makes easy. One thing to build, test, deploy and watch. A call between parts is a function call: fast, and it cannot be lost on a network. A change that touches three features is one commit and one release, and a transaction across them is one database transaction. It scales out by running more copies behind a load balancer.

What it makes hard. Every team releases together, so with many teams, releases queue and one broken feature can hold up all of them. The whole application scales as one, even if only search needs more capacity. And without discipline, parts start reaching into each other's code and tables until nothing can change alone.

The modular monolith. One deployable whose code is split into modules with clear boundaries: each module owns its tables and exposes a small interface, and others may only use that interface. It keeps the monolith's simplicity while keeping the parts apart, and if one module later needs to become its own service, the boundary is already drawn.

A company known to use it. Shopify runs its core commerce application as a monolith of over 2.8 million lines of Ruby, and in 2019 described turning it into a modular monolith rather than splitting it into services (Kirsten Westeinde, "Deconstructing the Monolith", Shopify Engineering, 2019).

So start with a monolith, keep its modules apart, and split a module out only when a real pressure calls for it.