Service Granularity: Right-Sizing Services

One of the most common questions in microservices architecture is: How big should a microservice be? Should a service contain just a few hundred lines of code? Should every business function have its own service? Or is it acceptable for a service to contain thousands of lines of code and support multiple related operations?

The answer is that there is no ideal service size. A microservice is not defined by its lines of code, number of endpoints, or database tables. What matters is whether it has a clear responsibility and can be developed, deployed, and operated with reasonable independence.

Consider an e-commerce platform. You could create a single Order Service that handles order creation, order items, order history, cancellation, and returns. Alternatively, you could split these responsibilities into five separate services. Both designs might appear reasonable, but they introduce very different trade-offs.

Smaller services can provide greater independence, but they also increase communication and operational complexity. Larger services are easier to coordinate internally, but they can become difficult to maintain as responsibilities grow. Finding the right balance is called service granularity.

In this chapter, we'll explore how to determine the appropriate size of a microservice, recognize services that are too large or too small, and make practical trade-offs.