Understanding Granularity in Microservices: Part 1

Every feature within an application can potentially shine as its own microservice! The essence of "micro" emphasizes precision and focus. Yet, how do we define the ideal scope for a microservice? By segmenting services to address specific functions, we encourage a more resilient, flexible architecture. Breaking a service into smaller, specialized pieces can make your system more flexible and easier to manage. This article dives into the challenges that make it tricky to figure out the ideal service size, known as granularity disintegrators, and offers insights on how to handle them.

?

Granularity disintegrators are factors that influence the decision to further break down services in a microservices architecture or to keep them larger. These aspects often introduce challenges that require careful consideration when determining the size and scope of services. Disintegrators necessitate a balance between making services too fine-grained, which can lead to complexity and management challenges, and too coarse-grained, which can compromise the benefits of a microservices architecture, such as flexibility, scalability, and independence.

Service Scope and Function

The service scope and function disintegrator focuses on defining the boundaries and responsibilities of a microservice. In microservices architecture, each microservice should have a specific function or a set of related functions.? This disintegrator should be the first driver for breaking up a service into smaller ones. When we analyze the service scope, we need to consider two aspects: cohesion and the total size of a component. Cohesion refers to how closely and effectively the operations within a particular service are connected or work together.

An example would be a Notification Service that does 3 things: send an SMS to the customer, email or a social media message. I know that it looks tempting to split this service into three separate services (one for SMS, one for email and another one for social media message), it would not be a good idea because these 3 services have a strong cohesion: the three services are doing one thing: notifying the customer. The ambiguity surrounding the Single Responsibility Principle often leads developers into difficulties when deciding on the granularity of services.

Scalability and Throughput

Scalability and Throughput as a granularity disintegrator addresses how the size and design of a service can impact its ability to scale and handle loads efficiently. Consider again the Notification service example, where this service is notifying the clients through SMS, email, and social media message. By analyzing the logs, we are getting the following numbers:

·??????? SMS notifications: 300.000/minute

·??????? Email notifications: 800/minute

·??????? Social media messages: 50/minute

We can see the difference between the number of SMS’s sent and the number of emails sent. If we keep all three microservices into one service, the email service and social media message service must unnecessarily scale to meet the demands of SMS notifications, impacting the cost and elasticity, regarding mean time to start (MTTS).

Fault Tolerance

Fault Tolerance as a granularity disintegrator examines how the division of services influences a system's resilience to failures. Services need to be structured so that they can maintain operations, even in the face of critical errors such as running out of memory or disk space. Consider again the Notification service example, where the entire functionality is on one service. If the email functionality has some fatal errors (ex: out of memory exception), the entire service stops working, including SMS and social media messages. Separating this modulith into three separate services provides a higher level of fault tolerance for the customer notification domain.

Security

When a service is secured, a common pitfall is to believe that sensitive data needs to be secured only in terms of storage. A common scenario is when we have a service that handles PCI data (Payment Card Industry) and non-PCI data. Let’s take as an example, a Customer Service that handles Customer Info and Customer Card Info Service that handles the credit card data. The first functionality has low security needs, while the latter has high security needs. Is this service is split into two services, we can make the service that handles credit card data more secure.