The architecture debate that has dominated software engineering discussions for over a decade continues to evolve. In 2026, we’re witnessing a fascinating shift: the emergence of sophisticated modular monoliths that challenge many assumptions about microservices superiority, while organizations that rushed into microservices are quietly consolidating back to simpler architectures.
This isn’t about declaring a winner. Rather, it’s about understanding when each approach delivers genuine business value versus when it creates unnecessary complexity that slows teams down and drives up costs.
1. The Evolution of the Monolith
The traditional monolith—a single deployable unit where all code lives in one repository—has gotten an unfair reputation. When developers speak disparagingly about monoliths, they’re often describing poorly structured codebases where everything depends on everything else. But this isn’t an inherent property of monolithic architecture; it’s a failure of software design.
Modern modular monoliths represent a middle ground that preserves the operational simplicity of a single deployment while enforcing strong internal boundaries. Companies like Shopify have demonstrated that monoliths can scale to enormous transaction volumes when properly architected. Their core platform handles millions of merchants and billions of dollars in transactions annually, yet remains fundamentally monolithic in deployment model.
The key distinction lies in how modules interact. In a well-designed modular monolith, modules communicate through defined interfaces, maintain separate database schemas within the same database, and could theoretically be extracted into separate services if needed. This approach provides the architectural rigor of microservices without the operational overhead.
According to a 2025 survey by the CNCF, approximately 42% of organizations that initially adopted microservices have consolidated at least some services back into larger deployable units. The primary drivers cited were debugging complexity, operational overhead, and network latency issues that impacted user experience.
2. The Microservices Reality Check
Microservices promised independent deployability, technology diversity, and team autonomy. These benefits are real, but they come with substantial costs that many organizations underestimated.
Amazon’s often-cited transition to microservices happened gradually over many years, with teams carefully identifying service boundaries based on actual business domains and traffic patterns. The two-pizza team concept worked because Amazon had the engineering maturity, tooling investment, and organizational structure to support it. Most companies attempting to replicate this pattern lack one or more of these prerequisites.
The complexity manifests in several ways. Network calls that were once in-process function calls now traverse HTTP boundaries, introducing latency and failure modes. A simple feature that touches multiple services requires coordinating deployments across teams. Debugging a production issue means tracing requests across dozens of services, each with its own logs and monitoring.
Netflix, one of microservices’ strongest advocates, openly acknowledges running over 700 microservices. Their engineering blog details the extensive tooling infrastructure required to make this work: sophisticated service mesh implementations, custom deployment platforms, comprehensive observability stacks, and chaos engineering practices to handle inevitable failures. This level of investment makes sense for Netflix’s scale and business model, but it represents millions of dollars in engineering time and infrastructure costs.
3. Communication Patterns and Their Hidden Costs
The shift from in-process method calls to network communication fundamentally changes application behavior. In a monolith, a function call typically completes in microseconds. In a microservices architecture, even a fast HTTP call adds milliseconds of latency—often 10-50ms for internal service-to-service communication when accounting for serialization, network transit, and deserialization.
This might seem trivial, but it compounds quickly. A user request that triggers calls to five services sequentially can easily add 150-250ms of latency just from network overhead. Real-world architectures often involve much more complex call chains, particularly when services need to aggregate data from multiple sources.
The common solution is to move toward asynchronous communication patterns using message queues or event streams. Technologies like Apache Kafka enable eventual consistency models where services publish events and other services react to them. This approach can improve performance and resilience, but introduces new complexities around message ordering, duplicate handling, and debugging distributed transactions.
| Communication Pattern | Latency | Consistency | Complexity | Best For |
|---|---|---|---|---|
| In-process calls (monolith) | <1ms | Strong | Low | Most business logic |
| Synchronous HTTP | 10-50ms | Strong | Medium | Request-response workflows |
| Asynchronous messaging | Variable | Eventual | High | Events, background processing |
| GraphQL federation | 20-100ms | Strong | High | Complex data aggregation |
A 2024 study by DZone found that teams spent an average of 35% more time on debugging in microservices architectures compared to modular monoliths, primarily due to the distributed nature of request flows and the difficulty of reproducing issues locally.
4. Data Management: The Thorniest Problem
Perhaps no aspect of microservices causes more ongoing friction than data management. The microservices ideal suggests each service should own its data completely, with no shared databases. This provides clear ownership boundaries and prevents coupling through database schema.
In practice, business data doesn’t divide neatly along service boundaries. Customer information might be needed by billing, shipping, analytics, and customer service systems. The microservices approach typically involves either duplicating this data across services (with eventual consistency), or having each service call back to the customer service to retrieve needed information.
Both approaches have significant drawbacks. Data duplication requires sophisticated synchronization mechanisms and leads to scenarios where different services have inconsistent views of the same entity. Calling back for data creates tight runtime coupling and can lead to the dreaded distributed monolith—services that must be deployed together because they’re so interdependent.
In contrast, a modular monolith can use a shared database with schema-level isolation. Different modules maintain their own tables and communicate through defined service interfaces, but database transactions ensure consistency. When a customer updates their address, all modules see the change immediately and atomically.
The Saga pattern emerged as a way to handle distributed transactions across microservices. It involves orchestrating a sequence of local transactions with compensating transactions for rollback scenarios. While elegant in theory, implementing Sagas correctly is notoriously difficult. A failed partial transaction might leave the system in an inconsistent state until compensating transactions complete, and ensuring idempotency of each step requires careful design.
Organizations that successfully operate microservices at scale typically invest heavily in data platform teams that build sophisticated replication, change data capture, and event streaming infrastructure. This is specialized expertise that smaller teams struggle to develop and maintain.
5. Team Organization and Conway’s Law
Conway’s Law observes that organizations design systems that mirror their communication structures. This principle cuts both ways in the microservices versus monolith debate.
For companies with multiple autonomous teams working on different business domains, microservices can align architecture with organizational structure. Each team owns their services end-to-end, making their own technology choices and deployment decisions. This autonomy can accelerate development when teams are mature and domains are well-understood.
However, Conway’s Law also means that poorly defined team boundaries will result in poorly defined service boundaries. Organizations that hastily divided teams before understanding their domain often end up with services that need constant cross-team coordination. The promised independence becomes an illusion, and the overhead of maintaining service boundaries becomes pure cost.
Modular monoliths can work effectively with multiple teams when those teams coordinate their work through pull requests and code review. A well-structured codebase with clear module boundaries and comprehensive tests allows teams to work independently most of the time, coming together only when work crosses module boundaries. This mirrors how teams in organizations actually interact—mostly independent with periodic coordination.
A key consideration is team size and distribution. According to research from Thoughtworks, organizations with fewer than 50 engineers rarely see net benefits from microservices, as the coordination overhead exceeds the independence gains. Geographic distribution does favor microservices, as it allows teams in different time zones to work more independently.
6. Testing Strategies and the Feedback Loop
Fast feedback loops are essential for developer productivity. In a monolith, running the entire application locally is straightforward. Developers can set breakpoints, inspect state, and understand exactly how their code behaves. Unit tests run in milliseconds, and integration tests execute against the complete application in seconds.
Microservices fragment this experience. Running the full application locally might mean orchestrating dozens of services, databases, and message queues. Many organizations resort to shared development environments in the cloud, but this introduces latency in the feedback loop and resource contention between developers.
Testing strategies adapt accordingly. Contract testing using frameworks like Pact allows teams to verify that service interfaces match expectations without running all services together. This enables independent deployment but requires discipline to maintain contracts and doesn’t catch integration issues until later in the development cycle.
End-to-end testing becomes significantly more complex and brittle. A test that spans five services has five times as many failure points, and debugging which service caused a test failure requires sophisticated tracing. Many organizations find their end-to-end test suites becoming flaky and slow, sometimes taking hours to run and requiring constant maintenance.
| Testing Aspect | Monolith | Microservices |
|---|---|---|
| Local development setup | Minutes | Hours to days |
| Unit test execution | Seconds | Seconds |
| Integration test execution | Seconds to minutes | Minutes to hours |
| End-to-end test reliability | High (70-90% reliable) | Medium (40-60% reliable) |
| Debugging time | Fast (minutes) | Slow (hours) |
| Test environment cost | Low ($100s/month) | High ($1000s-$10,000s/month) |
Data compiled from Google’s Testing Blog and State of DevOps reports
The cognitive load on developers also increases substantially. Understanding how a feature works requires reading code across multiple repositories in different languages, each with different conventions and frameworks. This slows onboarding and makes knowledge transfer more difficult.
7. Deployment and Operational Complexity
Deployment frequency is often cited as a major microservices advantage. Each service can be deployed independently, allowing teams to move quickly without coordinating with others. This is true in theory, but the reality depends heavily on service boundaries and dependencies.
When services have well-defined boundaries and clear ownership, independent deployment works beautifully. A team can deploy multiple times per day with confidence. However, when service changes require coordinated deployments of dependent services, teams end up with complex deployment choreography that’s more fragile than deploying a monolith.
Database schema changes illustrate this challenge. In a monolith, schema migrations run as part of application deployment, with rollback procedures if issues arise. In microservices, schema changes might need to support both old and new service versions during a rolling deployment, requiring multi-phase migrations with backward-compatible intermediary states.
The operational burden of microservices extends beyond deployment. Each service needs monitoring, logging, alerting, security patching, and performance tuning. A team that once maintained one application now maintains ten, each with its own configuration, dependencies, and failure modes.
Organizations address this through platform engineering teams that build internal developer platforms—essentially “microservices as a service” for product teams. Spotify’s Backstage represents this approach, providing standardized tooling for service creation, deployment, and monitoring. Building and maintaining such platforms requires substantial investment, typically justifiable only for larger organizations.
Cloud costs also warrant careful consideration. Each microservice typically runs with some overhead to handle traffic spikes and ensure availability. Research from Cast.ai indicates that microservices architectures average 30-40% higher infrastructure costs than equivalent monolithic applications due to this overhead, additional networking infrastructure, and duplicated middleware.
8. When Microservices Win
Despite the challenges outlined, microservices remain the right choice in specific contexts. Organizations operating at massive scale inevitably hit points where monolithic architectures cannot handle their requirements.
Google, Amazon, Netflix, and Uber all operate microservices architectures because their scale demands it. When you’re handling millions of requests per second across global regions, the ability to scale individual components independently becomes essential. If one feature experiences a traffic spike, you can scale only that service rather than replicating the entire application.
Team size and autonomy needs also favor microservices. Organizations with hundreds of engineers cannot coordinate effectively as a single unit. Microservices enable parallel development by multiple autonomous teams, each moving at their own pace. The coordination cost of microservices becomes worth paying when it’s lower than the coordination cost of all teams working in a shared codebase.
Domain complexity sometimes necessitates service boundaries. When different parts of an application have radically different non-functional requirements—some need extreme reliability while others prioritize rapid experimentation—microservices allow each to optimize independently. A payment processing service might use Java with heavy testing and gradual rollouts, while a recommendations engine might use Python with machine learning frameworks and deploy multiple times daily.
Technology diversity can provide genuine value when different problems call for different solutions. Using a specialized database for full-text search (Elasticsearch) or time-series data (InfluxDB) alongside your primary relational database might justify service boundaries. However, technology diversity also fragments expertise, so this benefit should be weighed carefully against maintenance burden.
9. When Modular Monoliths Win
For the majority of applications—particularly those earlier in their lifecycle—modular monoliths provide a better balance of architectural discipline and operational simplicity.
Startups and small teams benefit enormously from monolithic architectures. The ability to iterate quickly with simple deployment and debugging far outweighs any scalability concerns that might emerge later. As the famous saying goes, “You should be so lucky to have scaling problems.” Most applications never reach the scale where microservices become necessary.
Even established companies have found success with modern monoliths. Shopify serves millions of merchants handling billions in transactions annually with a primarily monolithic architecture. They’ve invested heavily in modularization, tooling, and testing practices that allow their monolith to scale both technically and organizationally.
Domain uncertainty favors monoliths. When you’re still discovering what your application needs to do and how different features relate to each other, the flexibility to refactor across boundaries is invaluable. Extracting code into a service locks in interface decisions that might be wrong, and merging services back together is painful. A monolith allows experimentation and learning without premature commitment.
Cost sensitivity tips the scales toward monoliths for many organizations. The infrastructure savings, reduced operational overhead, and smaller platform engineering requirements translate directly to lower costs. For businesses where technology is a cost center rather than a primary differentiator, these savings are significant.
10. The Hybrid Path Forward
Increasingly, sophisticated organizations are adopting hybrid approaches that combine elements of both architectures. A modular monolith might extract performance-critical or independently scalable components into separate services while keeping most business logic consolidated.
This pattern appears commonly with asynchronous workloads. The main application serves user requests as a monolith, publishing events to a message queue. Background services process these events independently—sending emails, generating reports, updating analytics. This preserves operational simplicity for the critical user-facing path while allowing flexibility for background processing.
Another common pattern involves extracting services at the edges. Authentication, rate limiting, and API gateways often run as separate services fronting a monolithic application core. This allows independent scaling of entry points without fragmenting business logic.
The key is making extraction decisions based on actual need rather than theoretical benefits. When a particular component genuinely requires independent scaling, has different operational characteristics, or benefits from team isolation, extraction makes sense. But keeping things together until there’s clear evidence otherwise prevents premature optimization.
11. Cost and Operational Complexity: The Real Numbers
Let’s examine the actual costs involved in each approach for a mid-sized application with moderate traffic requirements.
Modular Monolith Infrastructure:
- Application servers: $500-1,000/month
- Database: $300-600/month
- Cache layer: $100-200/month
- Monitoring and logging: $100-300/month
- CI/CD infrastructure: $100-200/month
- Total: $1,100-2,300/month
Microservices Infrastructure (10-15 services):
- Application servers: $2,000-4,000/month
- Databases (multiple): $800-1,500/month
- Message queue infrastructure: $300-600/month
- Service mesh/API gateway: $200-400/month
- Monitoring and logging: $500-1,200/month
- CI/CD infrastructure: $400-800/month
- Total: $4,200-8,500/month
Beyond infrastructure costs, personnel costs differ significantly. A modular monolith might require 1-2 operations-focused engineers. An equivalent microservices architecture typically requires 2-4 platform engineers plus additional operational burden distributed across product teams.
According to DevOps Salary Reports from 2025, platform engineers command average salaries of $140,000-180,000 annually. The additional 1-2 platform engineers required for microservices represent $140,000-360,000 in annual salary costs, dwarfing the infrastructure cost differences.
Bar chart comparing Modular Monolith vs Microservices
Modular Monolith
- ✓ Lower infrastructure overhead
- ✓ Requires 1-2 ops engineers
- ✓ Simpler debugging and monitoring
- ✓ ~$11,700/month total TCO
Microservices
- • Higher infrastructure costs
- • Requires 2-4 platform engineers
- • Complex distributed debugging
- • ~$27,183/month total TCO
12. Making the Decision
Choosing between microservices and modular monoliths requires honest assessment of your organization’s current state and genuine needs, not aspirational thinking about where you’d like to be.
Consider these key questions:
Do you have more than 50 engineers? Below this threshold, the coordination benefits of microservices rarely justify the operational costs. Team independence matters less when everyone can stay aligned through regular communication.
Do you have dedicated platform engineering capacity? Without 2-3 engineers focused on developer tooling, deployment infrastructure, and operational standards, microservices will create significant friction for product teams.
Are your domain boundaries well understood? If you’re still figuring out what features belong together and how data flows through your system, service boundaries will likely need frequent changes. This is much easier in a monolith.
Do you have specific scaling requirements? Microservices make sense when different components have dramatically different scaling needs. If everything scales roughly together, a monolith scales just as well with simpler operations.
What’s your team’s operational maturity? Microservices require sophisticated monitoring, distributed tracing, and debugging skills. Teams new to these concepts will struggle significantly with troubleshooting production issues.
The most successful organizations start with a modular monolith and extract services judiciously based on demonstrated need. This provides a clear migration path while avoiding premature complexity. Architecture evolves as understanding deepens and requirements change—trying to predict the perfect architecture upfront often leads to expensive mistakes.
13. What We’ve Learned
The microservices versus monolith debate has matured significantly. We’ve moved past the hype cycle where microservices seemed like a universal best practice, toward a more nuanced understanding of trade-offs.
Modular monoliths provide architectural discipline without operational overhead, making them ideal for most applications and teams. They enable rapid development, simple debugging, and straightforward operations while still enforcing the boundaries that prevent codebases from becoming unmaintainable tangles.
Microservices excel at massive scale and team independence, but their complexity is real and substantial. Organizations adopting microservices must invest in sophisticated tooling, platform engineering, and operational practices. For those that can make this investment and genuinely need the benefits, microservices enable capabilities that monoliths cannot match.
The evidence increasingly suggests that success comes not from choosing one architecture universally, but from matching architectural complexity to organizational and technical needs. Start simple, measure carefully, and add complexity only when clear evidence justifies it. This pragmatic approach delivers better outcomes than chasing architectural trends or cargo-culting the patterns that work for companies operating at dramatically different scales.
The best architecture for your next project isn’t microservices or a monolith—it’s the one that allows your team to deliver value quickly while keeping operations manageable. For most teams, most of the time, that’s a well-structured modular monolith with selective extraction of services where genuinely needed.
Eleftheria,
Thank you so much for the article; it’s well written and structured.
Now seems like a good time to start discussing deployment options—on-premises or in a cloud. The hype has died down, so it’s time to cut through the noise and figure out which option, or combination of both, is truly cost-effective.