Modular Monolith vs Microservices: What Fits Your Application?

The Microservices Tax and Industry Re-Evaluation

Over the past decade, microservices became the default architectural aspiration for software teams. Tech giants like Netflix, Amazon, and Uber famously published architectures featuring hundreds of independent services. Many engineering leaders assumed that adopting microservices was the prerequisite for writing "modern" enterprise software.

In recent years, however, a major industry re-evaluation has taken hold. Engineering organizations including Amazon Prime Video and Shopify published detailed architectural reports showing how consolidating fragmented microservices back into cohesive modular monoliths eliminated complex distributed race conditions and, in Prime Video’s monitoring platform, reduced infrastructure expenses by up to 90%.

The lesson is clear: microservices are not a badge of engineering excellence. They are an organizational compromise designed to solve team communication bottlenecks at massive scale, purchased at the cost of intense distributed systems complexity.

A project's target architectural topology should be locked in during discovery, as outlined in our guide on how to scope a custom software project before development.

What is a Modular Monolith?

Critics often equate a monolith with a "big ball of mud"—spaghetti code where every database table is queried from every controller, creating an unmaintainable tangle. But that is the fault of poor discipline, not monolith architecture.

A Modular Monolith applies Domain-Driven Design (DDD) principles within a single unified codebase. The application is strictly partitioned into distinct business modules (e.g., Billing, Inventory, Authentication, Notifications).

Each module encapsulates its own internal domain logic and private data models. Communication between modules occurs strictly through explicitly defined in-process public interfaces or domain events. No module is permitted to query another module's private tables directly.

This provides all the architectural cleanliness and separation of concerns associated with microservices, without requiring distributed networks, Kubernetes clusters, or service meshes.

Conway's Law: Architecture Follows Team Structure

Computer programmer Melvin Conway observed in 1967: "Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."

Netflix and Amazon adopted microservices because they had 2,000 engineers. At that scale, 100 teams cannot deploy a single shared codebase without tripping over each other's commits and blocking CI/CD pipelines. Microservices allowed each 8-person team to own a discrete service and deploy it independently.

If your engineering organization consists of 5 to 25 developers who communicate daily in the same Slack channels, adopting microservices forces you to pay the distributed systems tax without any of the organizational benefits. A single developer ends up having to manage 12 separate Git repositories and deployment pipelines just to release one feature.

Data Consistency: ACID Transactions vs Eventual Consistency

The greatest hidden cost of microservices is the death of database transactions. In a monolithic architecture sharing a relational database, moving money from Account A to Account B is handled with standard ACID transactions: BEGIN TRANSACTION, deduct, credit, COMMIT. If anything fails, the database rolls back atomically. Data integrity is guaranteed.

In microservices, Account A lives in the Banking Service database, and Account B lives in the Payment Service database. You cannot run a database transaction across two independent databases.

Engineering teams are forced to implement the Saga Pattern: complex choreographies of compensating transactions, outbox tables, message brokers, and reconciliation scripts. If the compensating transaction fails, you have an inconsistent distributed ledger that requires manual engineering intervention to resolve.

Operational Overhead and Observability Tax

In a modular monolith, reproducing a production bug is straightforward: run the application locally, set a breakpoint, and trace the function execution stack. Unit and integration tests run in seconds on a developer laptop.

In a distributed architecture, tracing a single user transaction requires distributed tracing infrastructure (e.g., OpenTelemetry, Jaeger), centralized logging aggregators, correlation IDs, and service mesh sidecars. When an API call returns a 500 error, finding which of the 14 upstream services failed requires specialized site reliability engineering (SRE) skills.

When Microservices Are Genuinely Justified

There are legitimate technical scenarios where extracting a microservice is the correct engineering decision:

1. Heterogeneous Resource Profiles: If one specific module requires specialized hardware—such as a video transcoding pipeline or a machine learning inference engine needing GPUs—while the rest of the app is a lightweight CRUD interface, separating that worker into a standalone service prevents over-provisioning the entire monolith.
2. Extreme Asymmetric Scaling: If 99% of your traffic hits a public telematics ingestion endpoint while your admin dashboard receives 10 visits a day, extracting the ingestion endpoint allows it to scale independently to thousands of instances.
3. Strict Regulatory Isolation: If PCI-DSS or HIPAA compliance mandates that payment or health data be stored in an isolated, audited VPC with restricted developer access, separating that domain into an audited service is appropriate.

Hypothetical Example: Financial Services Platform Architecture

Consider a hypothetical fintech startup, Veridian Asset Management, building a commercial loan syndication platform with a team of 9 engineers. An early architectural proposal recommended deploying 8 microservices: Auth, LoanOrigination, InvestorPortal, DocumentEngine, Escrow, Invoicing, Ledger, and Notifications.

After an architectural review, leadership recognized that managing 8 independent CI/CD pipelines, Kubernetes clusters, and distributed Saga orchestrations would consume more than half of the engineering team's daily capacity.

Veridian chose a disciplined Modular Monolith built with NestJS and PostgreSQL. They enforced strict module boundaries using TypeScript access barriers and private database schemas for each bounded context. All inter-module communication used in-process domain events.

The platform launched in four months instead of nine. Because all financial transfers ran inside atomic PostgreSQL transactions, the company experienced zero ledger reconciliation anomalies. When the team later expanded to 45 engineers, they extracted only their document conversion pipeline to a serverless worker pool while keeping the core transactional engine clean and unified.