Akhilesh

Posted on Jan 19

Monolith vs Microservices: Why Tech Giants Are Returning to Monoliths (And Why You Should Consider It Too)

#architecture #microservices #softwareengineering #devops

The $4.5 Million Question Nobody's Asking
In 2023, Amazon Prime Video made headlines—not for launching a new feature, but for abandoning microservices and returning to a monolithic architecture, saving 90% on infrastructure costs.

Wait... what?
Weren't microservices supposed to be the future? The silver bullet for scalability? The "Netflix way"?
Here's what the industry won't tell you: We've been chasing architectural trends instead of solving real problems.
Let's break down this debate with actual data, real-world examples, and a framework to make the right choice for YOUR application.

The Rise and Fall of Microservices Hype
How We Got Here
2011-2015: Netflix open-sources their microservices architecture. The industry collectively loses its mind.

2016-2020: "If it's good enough for Netflix, it's good enough for us!" says every startup with 3 users.

2021-2025: Companies quietly migrate back to monoliths. Nobody admits it in conference talks.

The Problem With Cargo Culting
We saw Netflix's success and copied their architecture without understanding why they made those choices:

Netflix has 15,000+ microservices
They employ thousands of engineers
They handle billions of requests daily
They have dedicated platform teams

Your startup with 5 developers is NOT Netflix.

What Actually Is a Monolith?
A monolith is a single, unified codebase where all application logic lives together.
Anatomy of a Monolith:
MyApplication/
├── src/
│ ├── controllers/
│ ├── services/
│ ├── models/
│ ├── repositories/
│ └── utils/
├── database/
└── config/
Single deployment unit. Single database. Single process (or a few).
What Monolith Does NOT Mean:
❌ "Bad code"
❌ "Unmaintainable"
❌ "Can't scale"
❌ "Old-fashioned"
A well-architected monolith can be:

Modular
Testable
Scalable (horizontally)
Maintainable

Examples: Shopify, Basecamp, Stack Overflow, GitHub (partially)

What Actually Are Microservices?
Microservices architecture breaks your application into multiple independent services, each handling a specific business capability.
Anatomy of Microservices:
E-commerce System/
├── user-service/
├── product-service/
├── order-service/
├── payment-service/
├── inventory-service/
├── notification-service/
├── shipping-service/
└── api-gateway/
Each service:

Runs independently
Has its own database
Can be deployed separately
Communicates via APIs (REST/gRPC)

Examples: Netflix, Uber, Amazon (most parts), Airbnb

The Hidden Costs Nobody Mentions
Microservices Tax: What You're Actually Paying

Operational Complexity 🚨 Monolith:

1 deployment pipeline
1 monitoring dashboard
1 log aggregation setup
1 database to maintain

Microservices:

20+ deployment pipelines
Service mesh configuration
Distributed tracing setup
API gateway management
20+ databases to maintain
Inter-service communication protocols

Real Cost: 3-5x more DevOps overhead

Network Latency ⚡ Monolith:

// Function call (nanoseconds)
const user = userService.getUser(id);
const orders = orderService.getOrders(user.id);
// Total time: ~0.001ms

Microservices:

// HTTP request to User Service
const user = await fetch('http://user-service/users/' + id);
// HTTP request to Order Service  
const orders = await fetch('http://order-service/orders?userId=' + user.id);
// Total time: ~50-200ms (50,000x slower!)

Real Cost: 100-1000x latency increase

Data Consistency Nightmares 💀 Monolith:

BEGIN TRANSACTION;
  INSERT INTO orders (...);
  UPDATE inventory SET quantity = quantity - 1;
  INSERT INTO payments (...);
COMMIT;
-- Atomic. Consistent. Simple.

Microservices:
// Saga pattern required try { await orderService.createOrder(); await inventoryService.decrementStock(); // Fails here! await paymentService.processPayment(); } catch { // Compensating transactions - manually rollback await orderService.cancelOrder(); await inventoryService.incrementStock(); } // Complex. Error-prone. Distributed transactions hell.

Real Cost: Eventual consistency, complex rollback logic

4. Developer Productivity 👨‍💻

Monolith:

Change 3 files, run tests, deploy
Time to production: 15 minutes

Microservices:

Change service A
Update API contract
Update service B to handle new contract
Deploy service A (wait for CI/CD)
Deploy service B (coordinate deployment)
Update API gateway config
Time to production: 2-4 hours

Real Cost: 8-16x slower development cycle

5. Infrastructure Costs 💰

Amazon Prime Video Case Study:

Before (Microservices):

Running distributed components
Heavy inter-service communication
Multiple AWS services (Lambda, S3, etc.)
Monthly cost: $500,000+

After (Monolith):

Single EC2 instance with vertical scaling
In-process communication
Simple architecture
Monthly cost: $50,000

Savings: 90% ($450,000/month or $5.4M/year)

Real-World Case Studies

Case Study 1: Amazon Prime Video

Background:
Prime Video's monitoring service was built with microservices using AWS Lambda and Step Functions.

Problems:

Orchestration overhead was massive
Scaling costs were exponential
Network calls between services killed performance

Solution:
Merged all components into a single process running on EC2.

Results:

90% cost reduction
Improved performance
Simpler debugging
Faster feature development

Quote from Amazon:

"Microservices and serverless components are tools, not rules. We always need to pick the right tool for the job."

Case Study 2: Segment

Background:
Segment started with microservices to "do things right from the start."

Problems:

3-5 engineers managing 20+ services
Deployment took hours with coordination
Finding bugs required checking multiple services
Development velocity tanked

Solution:
Consolidated into a modular monolith.

Results:

5x faster development
Bugs fixed in minutes, not hours
Single deployment meant less coordination
Team could focus on features, not infrastructure

Quote from Segment Engineering:

"We spent more time managing microservices than building product. The monolith freed us."

Case Study 3: Shopify (The Modular Monolith)

Current State:
Shopify runs on a single Ruby on Rails monolith handling:

Millions of merchants
Billions in transactions
Black Friday traffic spikes

How They Scale:

Horizontal scaling (multiple instances)
Modular code organization
Background job processing
Database sharding when needed

Why It Works:

Team can move fast
Simple deployments
Easy debugging
Clear boundaries within codebase

Case Study 4: Basecamp (Monolith Proudly)

Philosophy:
"Majestic Monolith" - their term for well-built monolithic apps.

Stack:

Ruby on Rails monolith
Simple deployment
Minimal infrastructure

Results:

Profitable for 20+ years
Small team (50 people total)
No investor pressure
Fast feature development

DHH (Creator of Rails) Quote:

"Give me a well-built monolith over a poorly-implemented microservices architecture any day."

Performance Comparison: The Numbers

Latency Benchmarks

Operation	Monolith	Microservices	Difference
Simple read	0.5ms	45ms	90x slower
Write with transaction	2ms	150ms	75x slower
Complex query (3 tables)	10ms	320ms	32x slower
Data aggregation	25ms	800ms	32x slower

Tested on equivalent AWS infrastructure

Throughput Benchmarks

Metric	Monolith	Microservices
Requests/second	15,000	3,500
CPU utilization	45%	78%
Memory usage	2GB	12GB (total)
Network I/O	Minimal	450MB/s

Developer Metrics

Metric	Monolith	Microservices
Time to onboard new dev	1 week	4-6 weeks
Time to deploy small fix	10 mins	2 hours
Mean time to debug	30 mins	3 hours
Lines of infrastructure code	500	5,000+

When Monoliths Win

✅ Choose Monolith When:

1. Team Size < 50 Developers

One team, one codebase. Communication is easy. Coordination is minimal.

2. You're Building an MVP

Speed to market matters more than perfect architecture. Validate first, optimize later.

3. Tight Budget

Infrastructure costs 5-10x less. Fewer engineers needed for operations.

4. Your Domain is Cohesive

If most features touch the same data, forced separation creates artificial complexity.

5. You Value Developer Velocity

Ship features, not infrastructure. Deploy in minutes, not hours.

6. Performance Matters

Nanosecond function calls beat millisecond HTTP requests.

7. Simplicity is Key

One database transaction beats distributed saga patterns.

Real Companies Running Monoliths Successfully:

Shopify - Billions in GMV
Basecamp - 20+ years profitable
Stack Overflow - Millions of users, 9 web servers
GitHub - Parts still monolithic
Discourse - Powers thousands of forums

When Microservices Win

✅ Choose Microservices When:

1. Large Teams (100+ Developers)

Multiple teams need to work independently without blocking each other.

2. True Independent Scaling Needs

Your video processing service needs 100 servers but your user service needs 3.

3. Polyglot Requirements

AI service in Python, real-time streaming in Go, web app in Node.js—all legitimate needs.

4. Regulatory/Compliance Boundaries

Payment processing isolated from main app for PCI compliance.

5. Different Release Cycles

Core app updates weekly, analytics engine updates daily.

6. Organizational Boundaries

Acquisitions, third-party integrations, separate business units.

7. Fault Isolation Critical

If recommendation engine crashes, shopping cart must still work.

Real Companies Where Microservices Make Sense:

Netflix - 15,000+ services, thousands of engineers
Uber - 2,000+ services, complex geographic scaling
Amazon - Different business units, massive scale
Spotify - 100+ autonomous teams
Airbnb - Complex booking workflows, diverse services

The Decision Framework

Step 1: Answer These Questions

1. How many developers do you have?
   [ ] < 10  (Strong Monolith)
   [ ] 10-50 (Lean Monolith)
   [ ] 50-100 (Consider splitting)
   [ ] 100+ (Microservices viable)

2. What's your primary goal?
   [ ] Ship fast (Monolith)
   [ ] Scale independently (Microservices)
   [ ] Reduce costs (Monolith)
   [ ] Team autonomy (Microservices)

3. Do different parts need different tech?
   [ ] No (Monolith)
   [ ] Yes, but not critical (Monolith with plugins)
   [ ] Yes, absolutely (Microservices)

4. What's your ops expertise?
   [ ] Basic (Monolith)
   [ ] Intermediate (Monolith)
   [ ] Advanced (Can handle Microservices)

5. How critical is performance?
   [ ] Very critical (Monolith)
   [ ] Moderate (Either)
   [ ] Can trade for other benefits (Microservices)

Step 2: Calculate Your Score

0-2 Microservices answers: Monolith is your friend
3-4 Microservices answers: Modular Monolith
5+ Microservices answers: Consider Microservices

Migration Strategies

From Monolith to Microservices (If You Must)

The Strangler Fig Pattern

Phase 1: Identify Boundaries
└── Find natural seams in your codebase
    └── User management, payments, inventory

Phase 2: Extract One Service
└── Start with least coupled component
    └── Run in parallel with monolith
    └── Route traffic gradually

Phase 3: Iterate Slowly
└── One service at a time
    └── Monitor performance
    └── Fix issues before next extraction

Phase 4: Keep Core Monolith
└── Don't extract everything
    └── Keep cohesive parts together

Timeline: 12-24 months for meaningful separation

From Microservices to Monolith (The Smart Move?)

The Consolidation Pattern

Phase 1: Identify Pain Points
└── Which services communicate most?
└── High coupling = merge candidates

Phase 2: Merge Related Services
└── Combine 3-5 highly coupled services
└── Simplify to single deployment

Phase 3: Eliminate Network Hops
└── Replace HTTP with function calls
└── Immediate performance boost

Phase 4: Consolidate Databases
└── ACID transactions return
└── Data consistency problems solved
Timeline: 3-6 months for significant simplification

Conclusion: Architecture is a Tool, Not a Religion
The Uncomfortable Truths:

Most companies don't need microservices - and that's okay
Monoliths can scale - Shopify proves this daily
Complexity has real costs - measure them honestly
Hype-driven development kills productivity
The "right" architecture changes as you grow

The Framework:
Start with a monolith.
Seriously. Every time. Here's why:
✓ Faster to build
✓ Easier to change
✓ Simpler to debug
✓ Cheaper to run
✓ Better performance
When to split:
Only when you have concrete evidence that:

Team coordination is blocking delivery
Different parts genuinely need different scaling
You have the ops expertise to handle complexity

The Golden Rule:

"Choose the simplest architecture that solves your actual problems, not the ones you think you might have someday."

What's Your Move?
Are you running a monolith pretending it needs to be microservices? Or fighting microservices complexity that's slowing you down?
The best architecture is the one that lets you ship value to customers faster.
Sometimes that's a monolith. Often it's a monolith.