Microservices vs Monolith: When to Split and When to Stay Merged

Microservices are the most cargo-culted architecture decision in software engineering. Teams copy Netflix’s architecture without Netflix’s scale, create distributed systems problems they did not have before, and end up slower than when they started. This guide covers the real trade-offs, the signals that indicate splitting is right, and the migration strategy that works.

⚡ TL;DR: Start as a monolith. Split only when: different scaling requirements per component, independent deployment is genuinely needed, teams are large enough that the monolith creates coordination overhead, or specific parts have fundamentally different tech requirements. Never split for splitting’s sake.

The real costs of microservices

# Costs that are invisible until you have them:

# 1. Network latency
# Monolith: function call = nanoseconds
# Microservices: HTTP/gRPC call = 1-50ms minimum
# A request that chains 5 services: 5-250ms added latency MINIMUM

# 2. Distributed transactions
# Monolith: ACID transaction across all data
BEGIN;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT; -- Either both happen or neither

# Microservices: no ACID across service boundaries
# Must use: Saga pattern, 2-phase commit, eventual consistency
# Complexity: 10x higher, bugs are subtle and hard to reproduce

# 3. Operational overhead
# Monolith: 1 deployment, 1 log stream, 1 monitoring config
# 10 microservices: 10 deployments, 10 log streams, 10 monitoring configs,
# service discovery, load balancers, circuit breakers, distributed tracing

# 4. Testing complexity
# Monolith: integration tests are straightforward
# Microservices: contract testing, consumer-driven testing, service mocks

When microservices ARE the right answer

# Signal 1: Different scaling requirements
# Video transcoding needs GPU instances — separate from REST API on CPU
# Search needs Elasticsearch cluster — separate from transactional DB
# Real-time events need different infrastructure than batch jobs

# Signal 2: Independent deployment genuinely needed
# Payment service: strict compliance, own release cycle, separate team
# Recommendation engine: ML team deploys daily, business logic weekly

# Signal 3: Team size creates monolith coordination overhead
# Conway's Law: architecture mirrors team communication structure
# 5 developers: monolith fine
# 50 developers: monolith causes merge conflicts, coordination overhead
# 500 developers: microservices align with team boundaries

# Signal 4: Fundamentally different tech requirements
# Python ML inference service + Node.js API + Go high-throughput service
# Different languages, runtimes, deployment needs

# Signal 5: Netflix/Amazon scale (you probably are not there)
# Netflix: 500M+ members, thousands of engineers
# Your startup at 1000 users: you are not Netflix

The Strangler Fig pattern — safe migration

# Never rewrite a monolith from scratch — strangle it gradually

# Step 1: Add a facade/proxy in front of the monolith
# All traffic: Client → API Gateway → Monolith

# Step 2: Extract one service, route its traffic through gateway
# Client → API Gateway → /payments/* → Payment Service (new)
# Client → API Gateway → /other/*     → Monolith (still handles rest)

# Step 3: Repeat for each domain, strangle monolith gradually
# Eventually monolith handles nothing and can be retired

# Key rules:
# - One service at a time
# - Data migration before code migration
# - Keep the monolith running throughout — never big bang rewrite
# - Feature flags to route % of traffic to new service

# Real example: Shopify
# Shopify ran as a Rails monolith from 2006 to ~2016
# Then gradually extracted: payments, notifications, search
# Monolith still runs core commerce logic
# They took 10 years — and they have 1000s of engineers

Monolith-first then split — the correct default

• ✅ Build monolith first — understand your domain before splitting it
• ✅ Split when you have concrete problems (scaling, team coordination, compliance)
• ✅ Use Strangler Fig — never big-bang rewrite
• ✅ Identify seams first — find natural domain boundaries in the monolith
• ✅ Migrate data before code — dual-write, then switch
• ❌ Never split because Netflix did — Netflix has 1000+ engineers
• ❌ Never split a monolith that is working fine at your scale
• ❌ Never create microservices that share a database — that is a distributed monolith

Microservices architecture connects directly to the Netflix-scale AWS architecture guide — showing what microservices look like when they are actually warranted. The Step Functions guide covers how to orchestrate distributed services without losing consistency. External reference: Martin Fowler on microservices.