Fast forward to 2025, and we’re witnessing a fascinating architectural reckoning. Companies that enthusiastically embraced microservices are now consolidating services, with some moving back to a more monolithic approach entirely. This isn’t a simple regression to the past but rather a nuanced reevaluation of the trade-offs involved in different architectural patterns.

The Promised Land of Microservices

Before we explore the pendulum swing, let’s remind ourselves why microservices became so popular:

• Independent deployability: Teams could release changes to their services without coordinating with other teams.
• Technical diversity: Different services could use different technologies that best fit their specific requirements.
• Scalability: Individual components could be scaled independently based on their specific load characteristics.
• Team autonomy: Conway’s Law could be leveraged, with team boundaries aligning with service boundaries.
• Fault isolation: Failures in one service wouldn’t necessarily bring down the entire application.

These benefits are real, and in many contexts, microservices still represent the right architectural choice. But as organizations gained experience with microservices in production, many began to discover that the benefits came with significant costs that weren’t always apparent at the outset.

The Reality Check: Challenges of Microservices

The challenges that have driven some organizations back toward more consolidated architectures include:

1. Operational Complexity

Microservices introduce substantial operational overhead. Instead of monitoring, deploying, and maintaining one application, teams suddenly need to manage dozens or hundreds. This requires sophisticated DevOps practices, monitoring solutions, and often, entirely new platform teams.

2. Distributed System Challenges

Distributed systems introduce challenges that don’t exist in monoliths: network latency, distributed transactions, eventual consistency, and partial failures. These complexities require different skills and patterns that many development teams weren’t prepared for.

3. Cognitive Load and Developer Experience

As systems grow more distributed, understanding the complete flow of a request becomes increasingly difficult. New developers face a steeper learning curve, and even experienced team members can struggle to debug across service boundaries.

4. Cross-Cutting Changes

Changes that span multiple services require coordination across teams, undermining the promised independence. Organizations found that many business changes naturally cut across the boundaries they had established.

5. Infrastructure Costs

Running many small services often consumes more total resources than a consolidated application. Each service has its own overhead in terms of runtime resources, monitoring, and potentially database connections.

Real-World Case Studies: The Journey Back

Let’s examine some notable examples of organizations that have reconsidered their microservices approach:

Segment: From 200+ Services to a Monorepo Monolith

Context: Segment, a customer data platform, initially embraced microservices enthusiastically, eventually growing to over 200 services.

The Challenge: As they scaled, Segment encountered severe operational complexity. Teams spent more time managing infrastructure than delivering value. Cross-service changes became coordination nightmares, and debugging across service boundaries proved extraordinarily time-consuming.

The Solution: In 2018, Segment began consolidating many of their microservices into a more monolithic architecture within a monorepo. They maintained service boundaries within the codebase but deployed them as a single unit. This approach preserved some benefits of service-oriented design while reducing operational complexity.

Results: According to their engineering blog, the move reduced infrastructure costs by approximately 30%, improved developer productivity significantly, and actually increased overall system reliability.

Key Quote: “We overestimated the value of independent deployability and underestimated the operational complexity of managing hundreds of services.”

Uber: Consolidating the Microservice Explosion

Context: Uber’s architecture grew from a monolith to thousands of microservices as the company expanded globally.

The Challenge: The explosion of microservices led to significant challenges in service discovery, dependency management, and operational efficiency. Teams struggled with “distributed monoliths” – technically separate services that couldn’t be changed independently due to tight coupling.

The Solution: While not abandoning microservices entirely, Uber has been actively consolidating services with related functionality and strengthening their service mesh and platform capabilities to better manage the necessary complexity. They introduced “domains” as a higher-level organizational concept above individual microservices.

Results: The consolidation efforts reduced latency in critical paths, improved overall system reliability, and enhanced developer productivity by reducing the cognitive load of working across many services.

Key Quote: “Having thousands of microservices is a form of tech debt. We’re not moving back to a single monolith, but we’re definitely more strategic about service boundaries now.”

Shopify: The Modular Monolith Approach

Context: While many companies were breaking up monoliths, Shopify deliberately maintained a modular monolith for their core commerce platform.

The Challenge: Shopify needed to scale to support millions of merchants while maintaining rapid feature development. They evaluated microservices but were concerned about the operational and cognitive overhead.

The Solution: Shopify doubled down on a well-structured, modular monolith with clear internal boundaries. They invested heavily in build tooling, testing infrastructure, and deployment automation to make their monolith operate with many of the benefits typically associated with microservices.

Results: Shopify has successfully scaled one of the world’s largest e-commerce platforms while maintaining developer productivity and system reliability. Their approach demonstrates that a well-designed monolith can scale to significant levels with the right practices.

Key Quote: “We’ve built tooling that gives us many microservices benefits—like isolation and developer independence—without the operational cost of maintaining hundreds of different services.”

Etsy: Targeted Microservices within a Monolith

Context: Etsy maintained a primarily monolithic architecture while selectively extracting specific functionalities into services.

The Challenge: Etsy needed to scale specific components of their platform without incurring the overhead of a full microservice transformation.

The Solution: Rather than wholesale migration to microservices, Etsy adopted a pragmatic approach of maintaining their core monolith while selectively extracting services only where clear scaling or isolation benefits existed.

Results: This balanced approach allowed Etsy to scale critical components while avoiding the operational complexity of a fully distributed system. Their selective service extraction based on specific needs rather than architectural dogma has served them well.

Key Quote: “We extract services when there’s a clear win, not because microservices are trendy. Our default is still the monolith, and that works for us.”

Soundcloud: Consolidating Microservices

Context: SoundCloud initially adopted microservices to scale their music streaming platform.

The Challenge: As their microservice architecture grew, they faced increasing operational costs, complicated deployments, and difficulty reasoning about the system as a whole.

The Solution: SoundCloud began a consolidation process, merging related services and focusing on stronger service boundaries for the microservices they retained. They moved from a “micro” to a “macro” service approach for many components.

Results: The consolidation reduced operational overhead, simplified their architecture, and allowed teams to focus more on product development rather than infrastructure maintenance.

Key Quote: “We found the sweet spot was fewer, more thoughtfully-designed services rather than many micro ones.”

Finding the Middle Ground: Service-Based Architecture

What’s emerging from these case studies isn’t a complete rejection of microservices in favor of monoliths, but rather a more nuanced approach that might be called “service-based architecture.” This approach has several characteristics:

1. Rightsized Services

Instead of pushing for the smallest possible services, organizations are finding value in “right-sizing” services around complete business capabilities. This might mean larger services that encompass an entire domain rather than splitting capabilities into numerous micro-components.

2. Monorepo with Clear Boundaries

Many organizations are adopting monorepo approaches that maintain clear module boundaries within a single repository, providing many of the benefits of separation without the operational overhead of fully separate services.

3. Selective Decomposition

Rather than decomposing everything, companies are being strategic about what belongs in a separate service, typically extracting components that have distinct scaling needs, team boundaries, or technology requirements.

4. Strong Platforms

Organizations successful with microservices are investing heavily in platform capabilities that abstract away much of the distributed systems complexity, making it easier for product teams to focus on business logic.

Practical Takeaways: What Should You Do?

Given this pendulum swing, how should organizations approach architecture decisions in 2025?

1. Start with a Monolith, Extract Strategically

Unless you have specific scalability requirements that can only be addressed through microservices, starting with a well-designed modular monolith is often the most efficient path. Extract services when clear scaling or isolation needs emerge, not preemptively.

2. Consider Team Structure Carefully

Conway’s Law is real – your architecture will reflect your team structure. Ensure that your architectural boundaries align with how your teams are organized. If your teams aren’t structured to support independent services, microservices will likely create more coordination overhead than they solve.

3. Invest in Developer Experience

Whether you choose microservices or monoliths, investing in excellent developer experience is crucial. This includes CI/CD pipelines, local development environments, testing infrastructure, and observability tools. With the right tooling, either architectural approach can be successful.

4. Be Wary of Distributed Monoliths

The worst of both worlds is a “distributed monolith” – technically separate services that must be deployed, tested, and reasoned about as a unit. If your services can’t be changed independently, you’re incurring the costs of distribution without the benefits.

5. Focus on Business Capabilities, Not Technology

Architectural decisions should be driven by business needs, not technological trends. Consider how your architecture supports your specific business requirements, team structure, and growth strategy.

Conclusion

The pendulum swing from microservices back toward more consolidated architectures doesn’t represent a failure of microservices as a concept. Rather, it reflects a maturing industry that’s moving beyond simplistic architectural dogma toward more nuanced, context-specific approaches.

As we’ve seen from the case studies, successful organizations are pragmatic about architecture, choosing the approach that best fits their specific context and needs. They recognize that architecture is a series of trade-offs, not a matter of following the latest trend.

The most important lesson from this pendulum swing may be that there are no silver bullets in software architecture. The right approach depends on your specific requirements, team structure, and business context. By understanding the trade-offs involved and learning from organizations that have gone before you, you can make more informed architectural decisions that serve your unique needs.

Whether you choose microservices, a monolith, or something in between, focus on building clear boundaries, strong abstractions, and excellent developer tooling. With these fundamentals in place, you’ll be well-positioned to deliver value regardless of which way the architectural pendulum swings next.