Modular monolith

A modular monolith splits code into modules by business domain: courses, billing, users, notifications. Each module has internal code nobody touches and a small public API that others use to talk to it.

Everything still deploys together, like a plain monolith. The difference is the rules: the billing module does not SELECT from courses tables, it calls courses.getPrice(courseId).

Boundaries must be checked automatically, or they will be gone in six months. Ruby has Packwerk from Shopify, Java has ArchUnit or Spring Modulith, TypeScript has the ESLint no-restricted-imports rule or dependency-cruiser.

Data is split too: a separate PostgreSQL schema per module (courses.*, billing.*) and no cross-schema joins. Reports that need data from several modules are built from a separate read model or through module APIs.

Modules can talk through in-process events: billing publishes PaymentSucceeded and courses unlocks the course. Later this bus is easy to swap for Kafka or RabbitMQ if a module moves out into its own service.

Extracting a well separated module into a service is cheap: its API already exists, its data is already apart, it has few dependencies. That is why the modular monolith is often called the best start for future microservices.

Many teams never take that step, because a modular monolith solves the main problem (teams not blocking each other) without new infrastructure. Shopify chose exactly this path for its Rails codebase with millions of lines.