DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • Top Load Balancing Algorithms: Choosing the Right Strategy
  • Stop Building Monolithic AI Brains, Build a Specialist Team Instead
  • Before You Microservice Everything, Read This
  • From Monolith to Containers: Real-World Migration Blueprint

Trending

  • Are Traditional Data Warehouses Being Devoured by Agentic AI?
  • The Agile Paradox
  • The Shift to Open Industrial IoT Architectures With Data Streaming
  • Micro Frontends to Microservices: Orchestrating a Truly End-to-End Architecture
  1. DZone
  2. Data Engineering
  3. Data
  4. How Small Should Microservices Be?

How Small Should Microservices Be?

There are tons of different perspectives regarding the best size and granularity of microservices. Which perspective is best for your project?

By 
Grygoriy Gonchar user avatar
Grygoriy Gonchar
·
Dec. 12, 16 · Opinion
Likes (8)
Comment
Save
Tweet
Share
15.9K Views

Join the DZone community and get the full member experience.

Join For Free

One of the most frequent questions within the implementation of microservices architecture is about size and granularity of microservices. How small should microservices be? Should a piece of software be split into multiple microservices or built as a single one? Trying to answer these questions, I came to some criteria to help me to make a decision.

Rather than focusing on pizza-size teams or the single responsibility principle, it’s better to stay pragmatic and focus on possible advantages and drawbacks of the design decision and challenge why a particular piece of software needs to be split. To do this, we need to model a part of the system that we want to build as multiple microservices candidates: define bounded contexts, main entities, and service capabilities around these entities. With a rough picture, we can think about benefits and drawbacks of such design from multiple perspectives.

Isolation of Changes Perspective

Do you expect changes in requirements of one candidate to be independent of another? By isolating the risk of changes to break something that wasn’t changed is reduced. Usually, changes in one bounded context change independently of others. The organization of microservices around business capabilities is a key success factor here. Since microservices provide a high level of isolation, they can help isolate changes.

Isolation of Static Services

Do we isolate services that don’t change frequently? While some requirements change frequently, others might change so rarely that we can treat microservice as static. Examples of such static microservices could be services responsible for sending emails or SMS, document or image format conversion, localization or translation, etc. In most of the system, such functionality changes rarely while main business features might change quickly. By isolating static functionality, we reduce the risk of breaking it and increase the necessity of testing.

Isolation of Business Critical Services

Do we isolate business-critical operations from the less critical? In some systems, we can divide functions that are vital and stop the system from being useful when they are unavailable. Such functionality for a web shop could be purchasing functionality while the recommendations system or wishlist are not that critical. Business-critical operations must be as much isolated as possible from non-critical functionalities. This will minimize the probability of affecting business-critical operations by troubles with non-critical functionality. Separate isolated microservice for pure critical functionality is usually a good idea.

Cohesion Perspective

Is one of the candidates fully independent in runtime from another? Mutual dependencies are a sign of high cohesion and bad candidates for different microservices.

Team Setup Perspective

Do you expect those candidates to be implemented by different development teams? The microservices approach is especially good to isolate work of one team from another.

Technology Perspective

Can the candidates be implemented more effectively with different technologies? Microservices make possible polyglot implementations where different programming languages and frameworks might be used.

Data Consistency and Transaction Boundaries Perspective

Can you accept eventual consistency between candidates? If not, this might be an issue since strong consistency in distributed systems is a complex topic. Are there any atomic business operation across the candidates? This might be not trivial to achieve with separate services.

Non-Functional Requirements Perspective

Are performance and availability requirements for those candidates different? It’s easier to deal with small and simple performance models where critical operations are isolated and implemented in the most optimal way. On the other hand, each remote call is a latency and risk of failure. The availability of the the business process relying on multiple microservices by default is lower than if the process relies just on one microservice.

Security Perspective

Is one of the candidates processing high-sensitive data while another is not? Least common mechanism security principle says that it’s safer to make processing of highly sensitive date separate from other data.

Give priority to questions that matter for your system. If the nswer is “yes” to most of them, then it might be a good idea to continue with those microservices candidates. Reiterating over each candidate and thinking about if any further segregated microservices would make sense will result in pragmatic decisions on microservices granularity.

microservice

Published at DZone with permission of Grygoriy Gonchar, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Top Load Balancing Algorithms: Choosing the Right Strategy
  • Stop Building Monolithic AI Brains, Build a Specialist Team Instead
  • Before You Microservice Everything, Read This
  • From Monolith to Containers: Real-World Migration Blueprint

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: