Why microservices anti-patterns are so expensive
Microservices architecture turns dependent, siloed systems into autonomous applications that deliver genuine business value. But its adoption comes with well-documented traps: the same mistakes that sank SOA twenty years ago are resurfacing, amplified by how easy it now is to spin up a new service in a Kubernetes cluster.
An anti-pattern is an approach that seems promising at first but ends up generating more problems than it solves, in contradiction with established best practices. Its cost is rarely immediate: it materialises six to eighteen months later, when velocity collapses, every release requires coordinating five teams and the cloud bill explodes. Spotting these traps early, ideally in architecture reviews, is the most profitable investment of a migration. The trap is all the more insidious because the first months often give an impression of success: the first services ship quickly, the demos impress, and the structural debt only reveals itself as the number of services and interactions grows.
These anti-patterns fall into three families: those of the adoption phase, those of design and migration, and those that surface in operations. The boundaries between families are porous, a bad adoption choice is often paid for in operations, but the grid helps structure architecture reviews.
Adoption anti-patterns: starting for the wrong reasons
The first pitfall is to credit microservices with magical virtues, as if merely adopting them were enough to fix development difficulties. Hype does not justify an architecture choice: if the underlying problem is untested code or a confused design, distributing it will only multiply it by the number of services. This bias has a name: cargo cult. Replicating the architecture of a web giant without its headcount, its volumes or its problems means paying the cost of a thousand-engineer organisation with a team of thirty.
Measuring success by the number of services created
Counting services as a progress indicator is a sign of short-sighted planning: the only success that matters is measured in business impact, deployment frequency, time to market, production stability. Likewise, focusing on deployment infrastructure while neglecting service decomposition causes teams to lose the big picture: tooling is necessary, it is never sufficient. A more honest indicator is to track the time between an idea and its release to production: if it does not improve after the migration, the architecture has solved nothing.
Migrating without software engineering foundations
Migrating without the basic foundations, clean code, automated tests, reliable CI/CD, review practices, sets the stage for failure: distributed complexity demands more rigour than the monolith, not less. Lack of coordination makes everything worse: when several teams adopt microservices in isolation, aligning goals on a common strategy becomes impossible and incompatibilities are discovered in production. Successful organisations sequence the effort: they first stabilise basic engineering on the monolith, tests, CI/CD, internal decoupling into modules, then extract a service only once a boundary has proven itself. Extracting a clean module is a routine operation; extracting a plate of spaghetti is a rewrite in disguise.
The distributed monolith: the worst of both worlds
The most widespread, and most expensive, anti-pattern is the distributed monolith: services split on paper but coupled in practice, through chains of synchronous calls, a shared database or releases that must be coordinated. You then pay the price of both architectures: the network latency and operational complexity of a distributed system, without the deployment autonomy that is its sole justification. The shared database is its most insidious variant: as long as two services write to the same tables, every schema change must be negotiated between all the teams involved, and the promised autonomy remains a slogan.
The warning signs to watch for
Three signals betray a distributed monolith: a release train where all services ship together, cross-team tickets for the slightest API change, and cascading outages where one unavailable service takes down ten others. The remedy involves versioned API contracts tested in CI, event-driven communication to decouple services in time, and a return to decomposition by business capability, even if that means re-merging services that are too entangled. A simple test settles the question: if you cannot deploy one service on its own, on a Tuesday afternoon, without warning anyone, you do not have microservices, you have a monolith with network fees.
Big bang data migration and misconfigured timeouts
At implementation time, a common anti-pattern is to try to split the application and migrate all its data at the same time. This massive, simultaneous migration multiplies the risk of error and rules out any rollback. Good practice is incremental: migrate functionality first, for instance with the strangler fig pattern, which gradually diverts traffic from the monolith to the new services, then establish data boundaries and contexts once usage has stabilised. Dual writes are a neighbouring trap: writing the data to your database then publishing the event as two separate operations always ends up diverging when a failure occurs between the two. The transactional outbox pattern, which records the event in the same transaction as the data, eliminates the problem at the root.
Circuit breakers rather than generous timeouts
Timeout settings are another sensitive point. Basing them on the performance of the service's database, for example by doubling the maximum observed response time, condemns consumers to long waits: every request has to sit for several seconds just to find out the service is not responding, while queues pile up upstream. The circuit breaker pattern, cut off quickly, probe regularly, restore automatically, is a far more robust alternative, now provided out of the box by service meshes. These mechanisms still need to be verified under real conditions: that is precisely what chaos engineering is for. Coupled with retries using exponential backoff and jitter, and with short timeouts set by the consumer according to its own latency budget, the circuit breaker turns a total outage into controlled degradation.
Reach-in reporting, duplicated gateways and technical decomposition
Accessing a service's database directly to produce reports creates interdependencies and violates the data ownership principle: the internal schema becomes a public API that can no longer evolve. It is better to distribute data through events, change data capture feeds an analytical warehouse in near real time, rather than querying the database directly and freezing its structure. This rule applies to every consumer: data teams, BI tools, export scripts, none of them should bypass the service's published interfaces.
API governance: centralise what must be centralised
Implementing throttling, authentication, orchestration and routing at each service level breeds inconsistency and a loss of transparency: a centralised API gateway ensures consistent governance, quotas, unified authentication, versioning, while services keep the business logic. A final design pitfall: organising services by technical concern (data access, business logic, orchestration) creates horizontal dependencies between teams and delivery bottlenecks. Services must remain autonomous business entities with complete, coherent functionality. The division of labour is constant: cross-cutting concerns go to the gateway, business logic stays in the services, and the platform's job is to make the compliant path easier than the artisanal one.
Nano-services and sprawl: when decomposition becomes the problem
Over-fragmentation is the mirror image of the distributed monolith: dozens of nano-services whose communication, monitoring and governance costs far exceed their value. Every additional service adds a pipeline, dashboards, on-call duty, dependencies to maintain and cognitive load, a bill teams systematically underestimate at the moment of the initial split. The phenomenon feeds itself: the easier it is to create a service, the more get created for bad reasons, one service per entity, per screen, even per developer.
Consolidating is not regressing
The industry has in fact corrected course: several major players have publicly documented merging overly fine-grained services and returning to larger services, or even to a modular monolith on some perimeters, with spectacular cost and latency gains as a result. Re-merging two services that always change together is not an admission of failure, it is architecture: granularity must follow the business and the teams, not a theoretical ideal of purity. The consolidation criterion is simple: two services that share the same release cycle, the same team and the same data have no reason to remain separate.
Succeeding with your microservices migration: method and governance
These anti-patterns share a common root: favouring technology or haste over business-focused thinking. Avoiding them requires strategic planning, decomposition aligned with business capabilities, regular architecture reviews and consistent governance across the organisation, API contracts tested in CI, automated fitness functions that continuously verify architecture rules, per-service SLOs. This governance must remain lightweight: a few automated rules verified continuously are worth more than an architecture committee examining every decision after the fact.
At Adservio, our architects and DevOps teams support the design and industrialisation of microservices architectures, from business decomposition to API governance, including audits of existing architectures to detect these anti-patterns before they become expensive. A typical audit takes a few weeks: mapping the real dependencies, measuring release coupling, reviewing contracts and data flows, then a remediation plan prioritised by business impact. The goal: secure the transformation and reap its expected benefits, without repeating the mistakes others have already paid for.
STAY POSTED
Get our next analyses and field notes straight to your inbox.
