Microservices: When the Monolith Actually Wins

Microservices are the default assumption in modern software architecture. If you're not breaking your monolith into microservices, you're probably being told you're doing it wrong.

But here's the uncomfortable truth: Sometimes the monolith actually wins.

Not always. Not even often. But for specific organizations with specific constraints, a well-designed monolith outperforms a distributed microservices architecture.

The cost of this mistake? Millions of euros. Companies spend years building microservices infrastructure, hiring distributed systems engineers, and writing operational complexity, only to discover they would have shipped faster and more reliably with a monolith.

This article is about knowing which camp you're in.

Why Microservices Are Assumed

Microservices have several legitimate advantages:

1. Independent scaling. Services can be scaled independently based on demand
2. Team autonomy. Teams own their service end-to-end
3. Technology heterogeneity. Different services can use different languages/frameworks
4. Continuous deployment. Services can be deployed independently
5. Resilience. Failure in one service doesn't cascade

These are real advantages. For the right organization.

But they come with costs that are often ignored:

1. Distributed complexity. Network calls replace function calls. Networks are unreliable.
2. Operational overhead. You need monitoring, logging, tracing across many services.
3. Testing complexity. You can't unit test the whole system. Integration tests are expensive.
4. Data consistency. Distributed transactions are hard. You need eventual consistency patterns.
5. Organizational overhead. You need infrastructure teams, SREs, and organized team structure.

The microservices advocate says: "Yes, but the benefits outweigh the costs."

For Netflix, Uber, and Airbnb? Absolutely.

For a 50-person company with a monolithic CRM? Maybe not.

When the Monolith Wins

Here are the specific scenarios where monolithic architecture is genuinely better:

1. Small Team (5-15 Engineers)

The monolith's main advantage: Simplicity.

With a small team, you don't need service boundaries for team organization. One team owns the whole application.

Microservices overhead for small teams:

• Need DevOps infrastructure (they become your 16th engineer)
• Need distributed monitoring (Prometheus, Jaeger, ELK)
• Need service mesh (Istio or Linkerd)
• Need deployment automation (GitOps, Helm)
• Need incident runbooks for multi-service failures

Monolith advantages for small teams:

• One deployment unit (deploy once, everything updates)
• One database (ACID transactions, no eventual consistency)
• Simple testing (integration tests aren't expensive)
• Simple monitoring (one application, one performance profile)
• Simple debugging (stack traces span the whole system)

The math:

• Microservices setup: 3-4 months
• Microservices management: 1 full-time engineer ongoing
• Monolith setup: 1-2 weeks
• Monolith management: 0.1 FTE engineer

For a 5-15 person team, that full-time engineer on infrastructure is a significant tax.

Companies in this situation: Most startups, bootstrapped companies, legacy software companies with small engineering teams.

2. Monolithic Business Domain

Not all applications benefit from service boundaries.

Some businesses are inherently monolithic: a tight system where everything affects everything.

Examples:

• Financial trading system (decision engine requires real-time consistency)
• CRM system (customers, deals, accounts are inseparable)
• ERP system (inventory, purchasing, receivables are interdependent)
• Accounting software (accounts, journals, ledgers require transactional consistency)

Breaking these into microservices creates more problems than it solves:

• Distributed transactions become complex
• Performance suffers (chattiness across services)
• Consistency becomes eventual (acceptable in e-commerce, not in finance)

The alternative: Monolith with modular internal structure. Core business logic is separated by module, not service. Each module has clear interfaces. But it's all deployed together.

This gives you code modularity without operational distribution.

3. Regulatory Requirements

Some industries require tight control over how data flows.

Examples:

• Financial services (GDPR + sector-specific regulations)
• Healthcare (HIPAA + national health regulations)
• Government (security clearances for data access)

With microservices, data flows across services. Each service requires compliance review. Audit becomes a nightmare.

Monolith advantage: Data stays in one place. One compliance review. One audit. One set of security controls.

For a monolith processing regulated data, you get:

• Clear data lineage (auditors understand data flow)
• Single point of control (one database, one access control)
• Simpler compliance (no inter-service data transfers)

This is why many finance and healthcare companies run monoliths.

4. Pre-Standardized Organization

Microservices assume team autonomy.

If your organization is pre-distributed (centralized architecture team, centralized database team, centralized operations), microservices fights organizational structure.

Example:

• Architecture team makes all infrastructure decisions
• Database team manages all databases
• Operations team manages all infrastructure
• Application teams execute, don't own

In this structure, microservices boundaries conflict with organizational boundaries.

A monolith is actually more appropriate: it matches the centralized structure.

Note: This isn't sustainable long-term (centralized structures don't scale). But for transitional periods, it reduces friction.

5. Latency-Sensitive Systems

Microservices require network calls between services.

Network calls are slower than local function calls (10-100x slower).

For latency-sensitive systems:

• Financial trading systems (microsecond latency matters)
• Real-time multiplayer games (millisecond latency matters)
• Autonomous vehicles (low latency is safety)

Microservices can still work (with careful placement and networking), but they add unnecessary complexity.

A monolith is faster and simpler.

6. Limited DevOps Resources

Microservices require operational expertise.

If you're in an industry with limited access to DevOps talent (government, certain European markets, specialized domains), microservices infrastructure becomes hard.

Example: A Swiss pharmaceutical company has strong software engineers but limited Kubernetes/distributed systems expertise. Microservices infrastructure requires hiring expensive talent.

A monolith can be managed by fewer specialists.

The Test: Is Microservices Right for You?

Before you commit to microservices, ask these questions:

Scoring:

• Mostly "monolith better": Stick with monolith
• Mostly "microservices better": Migrate to microservices
• Mixed: Hybrid approach (modular monolith as transition)

The Practical Approach: Modular Monolith

If you're uncertain, there's a middle ground: modular monolith.

Structure your codebase as if it were microservices (separate modules, clear interfaces, bounded contexts), but deploy as a single unit.

Advantages:

• Simplicity of monolith deployment
• Future flexibility of microservices structure
• Can evolve to microservices when (if) needed
• Code modularity without operational distribution

How to build one:

1. Organize code into modules (accounting module, CRM module, etc.)
2. Each module has well-defined API
3. Modules communicate through interfaces, not direct database access
4. Single deployment, but architectural flexibility

This buys you optionality: If your business needs microservices later, the modular structure makes migration easier.

When to Migrate From Monolith to Microservices

If you currently have a monolith, when should you migrate?

Migrate when:

• You have 30+ engineers (team coordination is becoming a problem)
• Different parts of the system scale differently (some services always overloaded)
• Different teams need independent deployment cycles
• You can afford a dedicated DevOps/SRE team
• Your business domain naturally separates into services
• You've hit specific performance bottlenecks that distributed systems can solve

Don't migrate if:

• You're doing it because "it's 2025 and everyone else is"
• Your team would become 50% infrastructure engineers
• Your business domain is tightly coupled
• Your latency requirements are strict
• You're uncertain about the benefits

The hard truth: Most companies that migrate to microservices do so too early. They add years of complexity without clear business benefit.

The Hidden Cost of Microservices

When evaluating microservices, account for all costs:

This isn't an argument against microservices. But if you're saving CHF 600K/year by staying monolithic, that's a real business advantage.

Microservices pay for themselves only if they enable something you couldn't do with a monolith.

The Bottom Line

Microservices are powerful. But they're not the universal solution.

Monolith is the right choice if:

• Small team (< 15 engineers)
• Tightly coupled business domain
• Limited DevOps resources
• Regulatory requirements demand tight control
• Latency is critical

Microservices is the right choice if:

• Large team (30+ engineers)
• Service boundaries match business domains
• You have DevOps expertise
• Different services have different scale requirements
• Independent deployment is essential

The practical advice: Start with a well-designed monolith. Migrate to microservices when you hit specific scaling or organizational problems.

Many companies skip the monolith phase and pay for it. Others stay monolithic too long and stagnate.

The trick is knowing which camp you're in.

Related reading:

• Kubernetes for Swiss SMEs: Where to Start
• Zero-Downtime Deployments: A CTO's Guide

Unsure about your architecture? Hidora helps enterprises design the right infrastructure: Consulting Services · Architecture Reviews · Managed Kubernetes