Software architects and developers who are designing microservices should be careful not to make the granularity of their services too fine-grained, though. Services whose granularity is too fine-grained are referred to as nanoservices and this is considered an anti-pattern.
A system with very small services tends to have more services and, as the number of services in a system increases, so does the amount of communication that must take place. Services use up network resources that are not infinite, and services are bound by these limitations. Having too many services can lead to the reduced performance of your services and of your overall application.
When a system has many nanoservices, there is also an increase in the overall overhead for the services. Each service requires some management, including things such as configuration and entry into a service registry. Larger numbers of services lead to increasing amounts of overhead.
Nanoservices can lead to fragmented logic. If a single business task that fits well into a single, cohesive service is decomposed further into multiple, smaller services, the logic becomes separated. Making services unnecessarily small is part of the nanoservice, anti-pattern.
When the overhead of a service outweighs its utility, then it is a nanoservice and refactoring should be considered. Nanoservices can be refactored by either combining multiple nanoservices into a new, larger service or moving the functionality of each nanoservice into an appropriate existing service.
There may be exceptions in which a nanoservice is appropriately sized and does not require refactoring, so it is always prudent to use your best judgment. Although you do not want your system to consist of too many nanoservices, sometimes, the functionality of a particular nanoservice simply does not belong anywhere else.