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.
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.
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.
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.
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.
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.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
