Microservices vs Monolith: When to Choose Each Architecture

The microservices narrative is compelling: break your monolith into tiny, independent services. Each team owns a service. Services scale independently. Deployment becomes safer because you're deploying smaller changes.

It sounds like the solution to everything.

In reality, we've seen both microservices and monoliths cause significant problems. The answer isn't 'which is better?' but rather 'what are the tradeoffs, and which do we accept?'

Understanding the Tradeoff

A monolith is a single application that contains all business logic. All code runs in one process. One database. One deployment.

Microservices split that into multiple independent services, each with its own process, data store, and deployment pipeline.

When a Monolith is the Right Choice

Monoliths are underrated. For many organisations, they're the correct choice:

• Small to medium teams: a single monolith is faster to build and deploy than setting up infrastructure for microservices
• Early stage products: you're still discovering what your product is. The business logic changes frequently. Microservices lock you into a structure you might not want.
• Straightforward domain: if your business logic is relatively cohesive, a monolith naturally represents it
• Limited operational capacity: microservices require sophisticated deployment, monitoring, and logging infrastructure. If you have small DevOps capacity, monoliths are safer.
• Performance-critical systems: monoliths can achieve better latency because services don't communicate over the network
• Strong ACID consistency requirements: if you need transactions that span multiple domains, a monolith with a shared database makes it simple

The Monolith Pain Points

Monoliths do have genuine limitations that become painful as systems grow:

• Scaling: if you need to scale one domain (e.g., payment processing) but others (e.g., administrative reporting) need less, you scale the entire application unnecessarily
• Deployment risk: every change requires redeploying the entire application. A bug in one service affects the whole system.
• Team independence: teams working on different features step on each other's toes in a shared codebase
• Technology choices: one language, one framework, one database. If one service needs a different technology, it's difficult to introduce.
• Reliability: a bug in one service can crash the entire application
• Complexity: monoliths accumulate complexity as they grow. The codebase becomes harder to understand and modify.

When Microservices Make Sense

There are real scenarios where microservices are the right choice:

• Large teams organised by domain: if you have separate teams owning payment, inventory, recommendations, etc., microservices align the code structure with your organisation
• Independent scaling requirements: some services peak at different times (e.g., checkout at holidays, recommendations every second), allowing targeted scaling
• Technology diversity: if different services genuinely need different technology stacks (Python ML service, Go API, Node.js web service), microservices enable that
• Long-running, independent services: some services (batch processors, workers, cron jobs) are natural to separate
• Fault isolation: if one service failing shouldn't crash others, separation helps (though modern patterns like circuit breakers can help in monoliths too)
• Organisational independence: teams move at different velocities, deploy on different schedules, make different technology decisions

The Hidden Costs of Microservices

Many organisations adopt microservices and discover unexpected costs:

• Distributed systems complexity: reasoning about systems where services call other services introduces complexity around timeouts, retries, partial failures, and network latency. This is genuinely difficult.
• Data consistency: in a monolith, you have transactions. In microservices, you need distributed transactions or eventual consistency patterns. This is complex and error-prone.
• Operational overhead: multiple services mean multiple deployments, multiple monitoring systems, multiple logs to investigate. You need sophisticated infrastructure to manage this.
• Testing complexity: integration tests that cross service boundaries are slow and flaky. You need contract testing, service mocking, and careful orchestration.
• Debugging difficulty: when something fails, you need to trace through multiple services and network calls. Tools help, but it's harder than investigating a monolith.
• Network latency: services that were previously in-process function calls now require network requests. This is orders of magnitude slower and can fail.

The Microservices Prerequisite: Maturity

Many organisations adopt microservices before they're ready. There's a maturity progression:

• Level 0: Single application, everyone making changes — monolith with weak boundaries
• Level 1: Monolith with clear internal boundaries — you've introduced domain-driven design but haven't separated services yet
• Level 2: Monolith with service-like boundaries — you have a service layer, clear interfaces between domains, can (theoretically) separate services
• Level 3: Microservices — you have separated services, independent deployments, service discovery, distributed monitoring

Most organisations should skip directly from Level 0 to Level 2. Stay at Level 2 until you have genuine pain that microservices solve. Many never need Level 3.

If you adopt microservices at Level 0, you'll be paralysed by distributed systems complexity.

Hybrid Approaches

Many successful organisations use hybrid approaches:

• Service-oriented monoliths: a monolith with clear service boundaries and interfaces. You can separate services later if needed.
• Strategic microservices: most of the system is a monolith, but a few services (payment, search, recommendations) are separate.
• Domain-driven monoliths: a monolith structured around domain boundaries so potential separation is clear.

These approaches give you flexibility: you can scale independent services when needed, but you avoid distributed systems complexity until necessary.

Questions to Ask

When designing a new system, ask:

• How many teams will work on this? If it's one team, a monolith is probably right. If it's five independent teams, services make sense.
• Do we have different scaling requirements? If everything scales together, a monolith works. If payment processing needs 10x more capacity than reporting, microservices help.
• Do we need different technology stacks? If yes, microservices. If we're comfortable in Python/Django, a monolith is faster.
• What's our operational maturity? Can we deploy reliably? Monitor multiple services? Manage distributed tracing? If not, microservices will be painful.
• What's our current pain point? If developers are stepping on each other's toes, that's a monolith pain. If we can't scale one service, that's a monolith pain. But 'everyone's using microservices' isn't a pain point.

A Realistic Path

A pragmatic approach:

• Start with a monolith with clear domain boundaries
• Structure it so potential separation is obvious (separate packages/modules per domain)
• As the team and system grow, identify which services genuinely need to scale or deploy independently
• Extract only those services to microservices
• Keep everything else monolithic
• Evolve based on real pain, not anticipation

This is called the 'modular monolith' approach and often provides the benefits of microservices without the complexity.

The Bottom Line

The monolith vs microservices debate often frames them as 'monoliths are old, microservices are modern.' That's not accurate.

For small teams, early-stage products, and cohesive systems, a well-structured monolith is the faster, simpler choice.

For large organisations with separate teams, complex scaling requirements, and operational maturity, microservices solve real problems.

Most organisations are somewhere in between and should resist the pressure to adopt microservices prematurely. Stay monolithic with clear internal boundaries until the pain of staying monolithic exceeds the pain of distributing systems.