Why Microservices Are Fading and Monoliths Are Making a Comeback

Microservices: The Rise and the Reversal

For years the industry promoted microservices as the future, promising independent deployment, scalable teams, and clear responsibility separation. Companies like Amazon, Shopify, Basecamp, Segment, and even Google have recently begun moving back to monolithic architectures.

What Microservices Promise

Independent deployment

Scalable teams

Clear separation of responsibilities

Reality: The Hidden Costs

Hundreds of tiny repositories that few understand

Network latency from excessive inter‑service communication

Developers spending more time on infrastructure than on product

Difficulty pinpointing the source of problems

Anyone who has built a real‑world microservice system will recognize these pain points.

A Simple Example

Consider an e‑commerce system split into services such as auth‑service, catalog‑service, cart‑service, order‑service, and notification‑service. While this looks clean, the practical consequences quickly add up:

Introducing Kafka or RabbitMQ to glue services together

Using Redis for shared sessions

CI/CD pipelines taking 30 minutes to deploy all services

Writing code solely for inter‑service communication

A single “simple” feature now requires changes in five services, three pull requests, and approvals from two teams.

Microservices Amplify Complexity

Microservices do not reduce complexity; they relocate it from code to the surrounding ecosystem. In a monolith, complexity lives in the codebase. In a microservice world, complexity appears in network latency, API contracts, data consistency, deployment pipelines, service discovery, and observability (logging, tracing, metrics).

Maintaining dozens of small Go services is often harder than maintaining a well‑structured large monolith.

Why Monoliths Are Returning

Monolithic architectures are simpler: everything resides in one place, debugging is straightforward, code changes are atomic, there are no cross‑service API nightmares, and local development does not require Kubernetes.

Modern tools (Go, Rust, Deno, Docker, Kubernetes) allow monoliths to scale effectively.

Real‑World Cases

Shopify and Segment, once fully invested in microservices, are migrating back to modular monoliths. Even Amazon, a pioneer of microservices, admits the model only works after solving many other challenges.

Modular Monoliths: A Hybrid Approach

Many companies now adopt a modular monolith: a single deployable unit with clear internal boundaries, organized like microservices but running in one process. This retains responsibility separation without the overhead of network calls, complex toolchains, or painful deployments.

In Go, this can be achieved by splitting the codebase by package or domain, e.g.:

/cart
/order
/notification

Although still a single application, it offers the benefits of modularity.

When to Choose Microservices

Scale of millions of users

Multiple product teams moving at high speed

Robust observability and deployment pipelines already in place

When a Monolith May Be Better

Engineering team smaller than 50 people

Focus on a single product

Infrastructure overhead outweighs feature development

In such situations, a monolith can rescue the team by reducing complexity and improving developer velocity.

Final Thoughts

Technical trends ebb and flow; we may have over‑engineered with microservices. The best architecture is the one that lets your team sleep peacefully, not necessarily the most fashionable one.