Modular Monolith

A single deployable application organized into well-bounded internal modules with explicit contracts, instead of distributed services.

A modular monolith is one process, one database, one deployment, whose internals are drawn as modules: billing, catalog, auth, notifications. The discipline is that modules talk to each other through defined interfaces and do not read each other's database tables directly. You get the maintainability boundaries of microservices without the network, the latency or the three deployment pipelines.

Why it matters to an indie builder: a small team cannot carry the operational load of distributed systems: cross-service tracing, partial failure handling, data synchronization, versioned contracts. The modular monolith keeps almost all of the organizational benefit (code you can reason about in pieces) at almost none of the runtime cost, and it preserves optionality: a module with a clean interface can be extracted into a service later if it ever genuinely needs to. Shopify and 37signals run some of the largest Rails applications on earth this way, which settles the scalability question for everyone smaller.

A concrete example: checkout. In the monolith, the orders module calls the payments module through an interface, both inside one database transaction: it commits or rolls back as a unit. The microservice version needs a REST call, a saga pattern, compensating transactions for failure, and eventual consistency on every path. Same feature, roughly ten times the operational surface.

Common mistakes: letting modules share tables, which erases the boundary the day billing queries the orders schema directly (enforce separation at the schema level and review cross-module reads like you would review a public API), skipping module-level test suites (they are what makes future extraction possible), and splitting into services prematurely because it sounds serious. The architecture-related technique blocks on IndieBoot, starting with monolith-first, cover the decision path.