The Modular Monolith in 2026: Why Teams Are Leaving Microservices Behind
Derar SattoufArchitecture
The Modular Monolith in 2026: Why Teams Are Leaving Microservices Behind
For nearly a decade, microservices were preached as the default architectural destination for any software engineering team with ambitions to grow.
Startups with barely ten engineers split their applications into twenty microservices, orchestrated them through complex Kubernetes clusters, set up distributed tracing via OpenTelemetry, and traded simple in-memory function calls for network-bound gRPC endpoints.
By 2026, the industry is experiencing a profound collective hangover.
Engineering leadership realized that microservices did not eliminate complexity; they merely transferred it from the application layer to the network and infrastructure layers. Teams spent more time debugging distributed race conditions, synchronizing schema changes across repositories, and tuning Kafka clusters than shipping product features.
The pragmatic consensus in 2026 has swung decisively back toward the Modular Monolith.
A modular monolith delivers the team autonomy, clean encapsulation, and domain-driven design promised by microservices, but does so within a single deployable unit. It eliminates network serialization latency, avoids distributed transactions, simplifies CI/CD, and enables atomic cross-domain refactoring.
This guide explores how to design, enforce, and operate a true modular monolith in modern full-stack environments.
TL;DR
- The Microservices Tax: Network hops, distributed sagas, dual-writes, data desynchronization, and Kubernetes infrastructure overhead often outweigh the organizational benefits for teams under 200 developers.
- What a Modular Monolith Is (and Isn't): It is not a tangled "big ball of mud" monolith where any file can import anything. It is a single codebase with strictly enforced domain boundaries, private internals, and explicit public API surfaces.
- Enforcing Architectural Boundaries: Rely on compile-time tools like TypeScript Project References, dependency linting (
eslint-plugin-boundaries), and package workspaces rather than polite developer conventions. - Database Modularity: Organize your relational database by schemas (e.g.,
billing.*,users.*,orders.*). Prohibit cross-domain joins in application code while preserving the option for atomic ACID transactions. - Asynchronous Decoupling via In-Process Buses: Use in-memory event emitters paired with the Transactional Outbox pattern instead of deploying heavy message queues like Kafka or RabbitMQ prematurely.
1. The Microservices Hangover: Reality Catches Up
The architectural promise of microservices was compelling: independent deployments, autonomous teams, and isolated scaling. In practice, however, small and medium teams suffered from several compounding failure modes:
[The Distributed Monolith Nightmare]
User Request ──> API Gateway (50ms)
│
├──> Auth Service (15ms)
├──> User Profile Service (30ms)
└──> Order Service (80ms)
│
└──> Inventory Service (120ms)
│
└──> Notification Service (Failed! Distributed Rollback?)- The Fallacy of Independent Deployments: In theory, Service A can deploy without affecting Service B. In practice, almost every major business feature required synchronized schema and API changes across 3 to 5 microservices, resulting in fragile deployment choreography and coordinated release meetings.
- Distributed Transactions (The Saga Problem): When an operation touches billing, inventory, and user notifications across separate databases, you can no longer use a simple Postgres
BEGIN ... COMMITblock. You are forced to implement the Saga pattern with compensating transactions. If a step fails halfway through, writing reliable rollback logic across asynchronous queues is notoriously difficult. - The Observability Tax: Finding the root cause of an error required tracing correlation IDs across ten distinct microservice log streams, API gateways, and message brokers.
- Massive Infrastructure Bills: Running dozens of independent microservices meant paying for duplicate container overhead, idle memory buffers, NAT gateways, and specialized DevOps headcount to maintain Kubernetes clusters.
2. Defining the Modern Modular Monolith
A modular monolith is a single application deployable as a unified process, structured internally as independent, highly cohesive domains.
┌────────────────────────────────────────────────────────┐
│ Modular Monolith │
│ │
│ ┌─────────────────┐ Public API ┌───────────────┐ │
│ │ Auth Module │<──────────────>│ Order Module │ │
│ │ - internal/ │ │ - internal/ │ │
│ │ - api.ts │ │ - api.ts │ │
│ └────────┬────────┘ └───────┬───────┘ │
│ │ │ │
│ │ Direct In-Memory Function Calls │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Core Database (PostgreSQL) │ │
│ │ - auth_schema.* - orders_schema.* │ │
│ └──────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────┘The core tenets:
- In-Memory Communication: Module A calls Module B through typed TypeScript/Go functions in memory. Execution takes 0.001 milliseconds, with zero JSON serialization, zero gRPC marshaling, and zero network timeouts.
- Explicit Public Contracts: Each module has a strict entry point (e.g.,
index.tsorpublic-api.ts). Its internal implementations, helpers, and database queries are completely private and cannot be imported by other modules. - Domain-Driven Cohesion: Everything related to a specific business capability—domain models, business rules, API routes, and database tables—lives inside that module's directory.
3. Enforcing Boundaries at Compile Time
The fatal flaw of legacy monoliths was that boundaries eroded over time. An engineer in a hurry would import an internal database model from another domain, and within two years, the codebase was an untangleable spaghetti mesh.
In 2026, modular monoliths use automated compile-time enforcement so that forbidden cross-module imports fail the build immediately.
Directory Structure
src/modules/
├── billing/
│ ├── internal/ # Private to billing!
│ │ ├── stripe-client.ts
│ │ ├── invoice-repo.ts
│ │ └── calculations.ts
│ └── index.ts # Public API boundary
├── users/
│ ├── internal/
│ │ ├── password-hash.ts
│ │ └── user-repo.ts
│ └── index.ts # Public API boundary
└── orders/
├── internal/
└── index.tsCompile-Time Enforcement via ESLint
Using modern boundary linting (eslint-plugin-boundaries), you define strict boundary rules:
// eslint.config.mjs
import boundaries from "eslint-plugin-boundaries";
export default [
{
plugins: { boundaries },
rules: {
"boundaries/element-types": [
2,
{
default: "disallow",
rules: [
{
from: ["module:*"],
allow: [
// Modules can only import from other modules' public API!
["module:${from.module}", { filename: "index.ts" }],
],
},
],
},
],
},
},
];If an engineer inside src/modules/orders/ attempts to write:
// ❌ FAILS IN CI: Cannot import private internal file of another module
import { calculateTaxInternal } from "@/modules/billing/internal/calculations";The linter rejects the commit. They are forced to interact through the approved public contract:
// ✅ ALLOWED: Calling the approved public contract
import { getTaxEstimate } from "@/modules/billing";4. Database Strategy: Independent Schemas, Shared ACID
A common question is: If everything lives in one database, how do we keep data modular?
The solution is PostgreSQL Schemas.
Rather than dumping 150 tables into the default public schema:
-- Create distinct logical namespaces inside one Postgres database
CREATE SCHEMA users_domain;
CREATE SCHEMA billing_domain;
CREATE SCHEMA orders_domain;
CREATE TABLE users_domain.accounts (
id UUID PRIMARY KEY,
email VARCHAR(255) NOT NULL
);
CREATE TABLE orders_domain.orders (
id UUID PRIMARY KEY,
user_id UUID NOT NULL, -- Logical reference, no hard foreign key across schemas!
total_cents INT NOT NULL
);The Architectural Rules:
- No Cross-Schema Foreign Keys: The
orderstable storesuser_idas a plain UUID, rather than declaring a hardREFERENCES users_domain.accounts(id). This keeps domains conceptually decoupleable. - No Cross-Schema Joins: The Order module never writes a SQL query that joins
orders_domain.orderswithusers_domain.accounts. If the Order module needs user information, it queries the Users module through its public TypeScript API. - Atomic Transactions When Necessary: Unlike microservices, when a business workflow genuinely requires all-or-nothing transactional guarantees (such as placing an order and debiting account balance simultaneously), you can wrap both module operations in a single atomic database transaction.
5. Event-Driven Decoupling: The Transactional Outbox
When an event occurs in one module (e.g., OrderCompleted), other modules (such as Email Notifications, Analytics, and Loyalty Points) need to react without tightly coupling the checkout process.
In microservices, this required running Kafka or RabbitMQ. In a modular monolith, you use the In-Process Transactional Outbox:
[Checkout Transaction]
BEGIN;
1. Insert into orders_domain.orders (...)
2. Insert into event_outbox (event_type, payload, status)
VALUES ('ORDER_COMPLETED', '{"orderId": "..."}', 'PENDING');
COMMIT;
│
▼ (DB triggers or in-memory poller)
In-Memory Event Bus ──> BillingModule.handleOrderCompleted()
└──> NotificationModule.sendConfirmationEmail()Why this pattern is unbeatable:
- Zero Inconsistency: The event is written into the
event_outboxtable in the exact same transaction as the order. If the database rolls back, the event never fires. If the transaction succeeds, the event is guaranteed to be processed. - Zero External Infrastructure: You do not need to operate, monitor, or pay for a separate message broker cluster.
- Easy Future Extraction: If a specific event handler ever needs to be extracted into a separate background service later, you simply point the outbox reader to an external message queue without rewriting business domain logic.
6. When to Actually Split Out a Microservice
The modular monolith is not a dogma against microservices; it is the sensible prerequisite to microservices.
You should extract a module into an independent microservice only when one of these three strict conditions is met:
- Radically Different Compute Profiles: A service performs CPU-intensive video encoding, 3D rendering, or heavy machine learning inference that would exhaust the memory or CPU of your standard web API server.
- Independent Scaling Bottleneck: A specific endpoint receives 100,000 requests per second (e.g., high-frequency telemetry ingest), while the rest of the application handles 200 requests per second.
- Regulatory or Compliance Isolation: A payment or healthcare module requires strict SOC2 or HIPAA isolation where the operating team must not have access to general application code.
If you have designed your modular monolith cleanly, extracting a module into a standalone service is straightforward: its public API transforms into an HTTP or gRPC client, while its internal implementation moves into its own repository with zero refactoring of other domains.
7. Conclusion
Software architecture is an exercise in managing trade-offs. The last decade proved that prematurely distributed architectures incur a massive operational tax that drains team momentum.
By combining the developer velocity of a single repository with the structural discipline of compile-time boundaries and domain-driven design, the Modular Monolith represents the most balanced, robust architecture for modern software engineering teams in 2026.