Microservices vs Monolithic Architecture: Which Is Right for Your Product?

The Monolith Is Not the Enemy

The software industry spent a decade glorifying microservices. The pendulum is swinging back. DHH (Basecamp/37signals) published "The Majestic Monolith." Amazon published a blog post about migrating Prime Video from microservices back to a monolith, cutting costs 90%. Shopify runs one of the world's largest e-commerce platforms on a Rails monolith.

The lesson is not "microservices are bad." The lesson is: architecture must match your team size, operational maturity, and actual scale requirements — not aspirational scale requirements.

What Is a Monolith?

A monolith is a single deployable unit containing all application logic. Types:

• Ball of mud monolith: Spaghetti code, no internal boundaries. This is what people mean when they complain about monoliths.
• Modular monolith: Single deployable but with clear internal module boundaries. Domain-driven design applied within a single process. This is the right starting point.
• Distributed monolith: Multiple deployed services that are tightly coupled (deployments must happen together). Worst of both worlds — avoid this.

Microservices: Genuine Advantages

Advantage	What it enables
Independent scaling	Scale the checkout service 10x without scaling the user profile service
Technology freedom	Use Python for ML services, Go for high-throughput APIs, Node for real-time
Fault isolation	A crash in the recommendation service does not take down checkout
Team autonomy	Teams own and deploy their service independently
Codebase size	Each service is small and comprehensible in isolation

Microservices: Real Costs (Often Underestimated)

Cost	What it means in practice
Distributed system complexity	Network failures, timeouts, partial failures become everyday problems
Service discovery	Need Consul, AWS Service Discovery, or Kubernetes DNS
Distributed tracing	Need Jaeger, Zipkin, or Datadog to trace requests across services
API versioning	Breaking changes in one service can cascade to callers
Data management	No shared database — inter-service data consistency requires saga patterns or eventual consistency
Local development	Running 15 services locally requires Docker Compose configs and significant RAM
Operational overhead	Each service needs its own CI/CD pipeline, monitoring, alerting, log aggregation

A startup with 5 engineers maintaining 20 microservices is a common failure mode. The overhead consumes engineering time that should be spent on product.

Decision Framework

Start with a modular monolith if:

• Team size < 20 engineers
• Product is < 2 years old / still finding product-market fit
• Scale requirements are not yet proven (< 1M users or < 10K RPM)
• You do not have dedicated DevOps/Platform Engineering capacity

Consider microservices when:

• Specific components have proven, significantly different scaling requirements
• Multiple independent teams need to deploy without coordinating
• You have dedicated platform engineering capacity (Kubernetes, service mesh, observability)
• Domain boundaries are well-understood and stable

The Strangler Fig Migration Pattern When you are ready to migrate: do not rewrite everything at once. Extract services incrementally at well-defined domain boundaries. Common first extractions: authentication, notifications, image processing, payments.

The Modular Monolith Sweet Spot

A modular monolith with clear domain boundaries, a well-defined internal API between modules, and clean dependency management gives you:

• Single deployment (simple CI/CD)
• Single database (no distributed transactions)
• Easy local development
• Clear refactoring path to microservices when genuinely needed

Get expert architecture guidance for your product. Talk to our software architects → or contact us to review your architecture.