Microservices have been the dominant architectural trend for a decade. Netflix, Amazon, Uber — every large tech company uses them. So many startups assume microservices are the “correct” architecture. The reality: most startups and mid-sized businesses would be better served by a well-structured monolith. Here’s the honest picture.
What Is a Monolith?
A monolithic application has all functionality in a single deployable unit. User management, orders, notifications, and payments all live in one codebase and deploy together. This is the natural starting point for most applications — and many successful companies run on monoliths. Shopify, Stack Overflow, and Basecamp are notable examples.
What Are Microservices?
Microservices breaks the application into independently deployable services, each responsible for one capability. User service, order service, notification service — each runs in its own process, communicates via APIs or message queues. Each service can be deployed, scaled, and developed independently.
The Real Benefits of Microservices
Independent scaling: If your image processing service needs 10x more compute than user management, scale just that service. Monolith = scale everything.
Independent deployment: Changing the payment service doesn’t require redeploying the entire application. Teams ship on their own schedule.
Technology diversity: ML service in Python, real-time service in Node.js, core business logic in Laravel. Best tool for each job.
Team scale: When you have 5+ teams, a shared monolith creates coordination friction. Microservices give each team ownership and autonomy.
The Real Costs Nobody Tells You
Operational complexity: Instead of deploying one thing, you’re deploying 10–50 things. Each needs CI/CD, monitoring, logging, and alerting. You effectively need a full-time platform engineer just to manage the infrastructure.
Network latency: In a monolith, a function call is nanoseconds. In microservices, a service call is a network request — milliseconds. A single user request might fan out to 5–10 service calls. Latency compounds.
Distributed transactions: In a monolith, a database transaction is atomic. In microservices with separate databases, cross-service transactions require the Saga pattern or two-phase commit — significantly more complex.
Local development: Running the full system locally means starting 10+ services. Developer machines need significant resources just for the dev environment.
When to Use a Monolith
- You’re starting a new product. Always build a monolith first. You don’t understand your service boundaries until you understand your domain. Premature microservices lead to wrong service divisions that are expensive to fix.
- Team under 10 engineers. Coordination overhead of microservices with a small team slows everyone down.
- Moderate, predictable traffic. You’re paying the complexity cost without the scaling benefit.
- Startup / MVP phase. Optimise for learning and iteration speed. You can extract services from a monolith later when you actually hit limits.
When to Consider Microservices
- You have 5+ teams that need to deploy independently — team autonomy is the primary driver.
- Components have genuinely different scaling requirements (100x difference).
- Your monolith is genuinely unmaintainable due to coupling and team size.
- You have components that need fundamentally different technology for legitimate technical reasons.
The Middle Path: Modular Monolith
The most practical advice for growing companies: build a modular monolith. Well-organised code with clear bounded modules (users, orders, payments) that communicate through defined interfaces — not just shared database tables accessed everywhere. When you need to extract a service, the boundaries are already clear. This gives you organisational clarity without operational complexity.