What is a 'nanoservice' anti-pattern, and why is a service that's too small often worse than a monolith?

## What nanoservicing is A microservice architecture decomposes a system into independently deployable units, each ideally owning one bounded, cohesive slice of business capability along with its own data store. **Nanoservicing** is what happens when a team pushes this decomposition too far, splitting services along technical lines (a single endpoint, a single database column, a single CRUD verb) rather than along capability lines. A textbook example is splitting a 'User' domain into separate services for `CreateUser`, `UpdateUserEmail`, `UpdateUserAddress`, and `DeleteUser` — each with its own repository, deployment pipeline, and a slice of the same underlying table — when in reality these operations are one cohesive 'manage user profile' capability that a single team owns and that almost always changes together. ## Where it comes from Nanoservicing usually emerges from good intentions taken past their useful range. - The **Single Responsibility Principle**, correctly applied at the class or module level, gets misapplied at the deployment-unit level as 'each service should do exactly one thing,' and 'one thing' gets interpreted as 'one function call' instead of 'one business capability.' - It's also a reaction to **monolith pain** (long build times, tangled ownership, fear of touching shared code) and to **conference-driven development** that equates 'more services' with 'more modern.' - Teams new to microservices often lack a felt sense of the **fixed operational cost** every service carries, so they don't see the tax they're signing up for. ## The fixed overhead every service pays Every service — no matter how small — pays a fixed overhead: - its own **CI/CD pipeline** - its own **container image** and base-image patching - its own **health checks**, dashboards and alerts - its own **on-call runbook** - its own **versioning** and backward-compatibility contract - at least one **network hop** to reach it (with associated latency, timeout tuning, retry policy and circuit breaker) When the unit of business logic inside the service is tiny — one field update — that fixed cost dwarfs the value delivered. You get more services to patch for CVEs, more pipelines to keep green, more dashboards nobody looks at, and a request that used to be one in-process function call becomes a network round trip with its own failure modes. The promised benefits of microservices — independent scaling, independent deployability, fault isolation — rarely materialize at this granularity because these tiny services are so tightly coupled in their data and lifecycle that they must be deployed and reasoned about together anyway; you've paid for distribution without buying the isolation it's supposed to buy. ## Production symptoms - **Chatty inter-service communication** is the most visible production symptom: a single user action (e.g., 'update my profile') now requires the caller (a BFF, gateway, or another service) to orchestrate calls to four or five nanoservices, and if any one call fails partway through, you need compensating logic to undo the ones that already succeeded — essentially hand-rolling a distributed transaction (a saga) for something that used to be one local ACID transaction. - **On-call load spikes because incidents multiply**: an outage in 'UpdateUserEmail' doesn't just break email updates, it breaks every workflow depending on the chain of calls leading to it, and diagnosing this requires distributed tracing across many hops instead of reading one stack trace. - **Deploy coordination gets worse, not better**: because these services are so entangled, changing 'user' behavior often requires touching several nanoservices in lockstep, so the 'independent deployability' that justified splitting them in the first place doesn't hold. ## The corrective heuristic This pattern is documented widely enough to have a name — 'nanoservices' or the 'distributed monolith' antipattern — and practitioner accounts (echoing Sam Newman's writing in 'Building Microservices,' which shaped much of the mainstream vocabulary around service granularity) describe teams merging a dozen single-purpose services back into two or three cohesive services once the operational tax became visible in cloud bills, on-call fatigue, and slowed feature delivery. The corrective heuristic is to size a service around a bounded context or business capability — something that: 1. a small team can own end-to-end 2. changes for one reason 3. is large enough to amortize its fixed operational cost against real business value delivered