Microservices: The Truths No One Tells You Before You Migrate

SECTION 1

The uncomfortable truth: you probably don't need microservices

Microservices are sold as THE solution to every scalability and organizational problem. The reality? They create as many problems as they solve, and it took the industry ten years to admit it publicly. In 2026, the consensus has changed: the "micro-everything" era is behind us, the modular monolith is once again a fully legitimate reference architecture, and the real question is no longer "how to split" but "whether to split at all".

### The signals that argue for the monolith

Several signals indicate you should stay a monolith: a team of fewer than 15 developers, fewer than one deployment per week, traffic under 1,000 requests per second, a limited infrastructure budget, or no in-house DevOps/SRE expertise. In these contexts, the empirical rule remains merciless: a well-structured, modular, well-tested monolith consistently beats poorly built microservices, at a fraction of the operating cost and cognitive load.

This reframing is not a step backward: it's the recognition that the operating cost of a distributed system, on-call duty, observability, orchestration, inter-service security, is paid every month, whether or not the value shows up. Teams that split too early spend their time operating distributed plumbing instead of shipping product; those that structured a modular monolith keep the option of extracting later, when a real need justifies it.

SECTION 2

When microservices genuinely make sense

There are, however, contexts where splitting is the right call, provided it answers an observed problem, not a fashion. Two patterns dominate the legitimate cases: differentiated scaling and team autonomy.

### Differentiated scaling by load profile

When an application's components have very different load profiles, a monolith forces you to scale everything to satisfy the busiest component. A typical e-commerce example: Search takes 80% of traffic, recommendations 14%, checkout 5%, and payment 1%, yet the monolith has to be replicated as a whole, all or nothing. With microservices, each service scales independently: 50 pods for Search, 5 for recommendations, 10 for checkout, 2 for payment, with a direct gain in infrastructure efficiency.

### Team autonomy and deployment cadences

When teams have radically different cadences, microservices give them the autonomy they need: a Finance team deploying its billing service in Python once a week, a Logistics team deploying its shipping service in Go five times a day, a Data team shipping its analytics pipelines once a month. Each moves at its own pace, with its own stack, without blocking the others, that's where distributed architecture delivers real organizational value, aligned with Conway's law.

SECTION 3

The hidden costs: operational complexity, latency, and consistency

A monolith is one application to deploy, one database to monitor, one log stream, and relatively simple debugging. Twenty microservices means twenty applications to deploy, fifteen or more databases to watch, twenty log streams to correlate, and debugging that requires distributed tracing, now standardized around OpenTelemetry, to reconstruct a request's path across services.

### From in-memory latency to network latency

In a monolith, calls between components happen in memory, essentially free: fetching the user, checking stock, and processing payment takes on the order of 10 ms in total. With microservices, every call becomes a network call, 5 ms for the user service, 8 ms for inventory, 12 ms for payment, roughly 30 ms in all, not counting latency variance and the intermittent network failures you now have to treat as normal cases.

The third cost is the most structural: losing ACID transactions. In a monolith, order creation, stock update, and payment fit inside a single transaction, everything succeeds or everything rolls back. With microservices, consistency becomes eventual: the Order service creates the order, Inventory confirms the stock, but Payment can fail, and you have to orchestrate the rollback yourself across several independent services.

Add to that a cost that's rarely budgeted: cognitive load. Every additional service brings its repository, its pipeline, its dashboards, its dependency versions, and its conventions, and every developer has to hold an ever-larger map of the system in their head. That's precisely what internal platforms aim to reduce, by standardizing service templates and hiding the infrastructure behind golden paths.

@cite:anti-patterns-microservices

SECTION 4

Survival patterns: Saga, Circuit Breaker, and API Gateway

The Saga pattern manages distributed transactions: an orchestrated saga executes steps sequentially, create the order, reserve stock, charge payment, confirm, and triggers compensating transactions on failure. If payment fails, the reserved stock is released and the order canceled; every step has a counterpart that undoes what has already been done, making partial failure manageable rather than catastrophic.

The Circuit Breaker keeps failures from spreading: after a defined number of consecutive failures, the circuit opens and calls fail immediately without hitting the struggling service, giving it time to recover. After a delay, the circuit moves to a half-open mode to cautiously test the return to normal. Without this pattern, the failure of a single service can drag the entire call chain into a cascading outage.

The API Gateway provides the single entry point: all client requests go through a gateway that handles authentication, rate limiting, and load balancing before routing to the right service, so no client needs to know the address and rules of every individual service.

@cite:patterns-microservices-bonnes-pratiques

SECTION 5

Inter-service communication and the sidecar-less service mesh

Three communication options dominate. Synchronous REST/HTTP: simple and debuggable, but a source of coupling, latency, and cascading failures. Asynchronous message queues: a service publishes an event, "order created",without knowing who consumes it, bringing decoupling and resilience at the price of eventual consistency. And gRPC: strongly typed protobuf contracts, generated client and server code, and performance several times higher than REST for high-volume internal calls.

The right reflex is to choose asynchronous by default for business flows that tolerate a delay, notifications, billing, analytics, and to reserve synchronous calls for journeys where the user is waiting for an immediate answer. That simple trade-off eliminates a large share of cascading failures before you even need a circuit breaker.

### The service mesh in 2026: ambient and eBPF

The service mesh has changed shape: Istio's sidecar-less ambient mode has become the recommended deployment model, mTLS handled at L4 by a per-node ztunnel, L7 waypoint proxies only where needed, for a 60 to 70% reduction in resource consumption compared with classic sidecars. In parallel, Cilium and eBPF have established themselves as the standard for cloud-native networking. The mesh remains a serious investment nonetheless: adopt it only once the number of services justifies it.

SECTION 6

Distributed data: Database per Service and its consequences

The most widespread anti-pattern remains the shared database: when several services read from and write to the same database, the schema becomes hidden coupling, independent scaling and deployment become impossible, and tables suffer contention from competing services. That's a distributed monolith: all the drawbacks of both worlds, none of the benefits.

The Database per Service pattern gives each service its own database, which removes schema-level coupling but raises new questions: how do you query across several services, handle data duplication, guarantee consistency across databases? These questions are answered with API composition, domain events, CQRS, and sagas, never with direct SQL joins into other services' databases.

The transactional outbox pattern completes the set: rather than publishing an event and writing to the database in two separate operations, with the risk that only one of them succeeds, the service writes the event into an outbox table within the same local transaction, and a relay then publishes it to the broker. You get reliable publication without a distributed transaction, an essential building block for keeping sagas and projections consistent.

SECTION 7

Migrating without a big bang and checking your maturity before you jump

"Let's split the monolith into 20 microservices this weekend" is about the riskiest promise you can make: it concentrates all the risk into a few days, with no room to course-correct. The right approach is incremental, strangler-fig style: extract one service at a time, starting with the most independent one. A realistic sequence, weeks 1 to 4, authentication (clear boundary, low risk); weeks 5 to 8, notifications (asynchronous, no strong coupling); weeks 9 to 16, billing; then service by service, building on each extraction.

### Technical and organizational maturity checklist

Before migrating, check your technical capabilities: Kubernetes and containers mastered, automated CI/CD, distributed observability based on OpenTelemetry with a backend such as Grafana or Datadog, a service mesh or equivalent, infrastructure as code. And your organizational capabilities: autonomous cross-functional teams, a DevOps/SRE culture, an established on-call rotation, mature incident response. If fewer than 70% of these boxes are checked, stay a monolith or invest in these foundations first.

The golden rule hasn't changed, and at Adservio we defend it project after project: start as a monolith, modular, cleanly split into domains, and migrate to microservices only when the pain of the monolith durably exceeds the complexity of microservices. Microservices are neither a magic solution nor a mandatory step to scale: they're a trade-off between complexity and autonomy, worthwhile only in the contexts that justify it.

@cite:du-monolithe-aux-microservices

FAQ

Frequently asked questions