Dark energy force: segregate by characteristics

microservice architecture   architecting   dark energy and dark matter  

a dark energy, dark matter force

We can often improve an application by segregating subdomains by their characteristics, which include:

  • Resource requirements
  • Domain-specific software development regulations
  • Business criticality
  • Security
  • DDD subdomain type

It’s important to remember that whether the benefits of segregating subdomains by their characteristics outweighs the drawbacks depends on the application.

Let’s look at a few examples.

Segregating by resource requirements to improve scalability

A subdomain requires certain resources, such as CPU, GPU, memory, network bandwidth, storage, etc. It also requires a particular number of “instances” to achieve the desired throughput and availability. However, the unit of scaling in an application is a component, or more precisely, a component instance. This means that the component’s subdomains are scaled together, which risks over provisioning resources for some of its subdomains. If you package subdomains as separate services, you can scale them independently by, for example, using different EC2 instance types, which improves resource utilization and reduces cost.

Let’s imagine, for example, the following scenario. There are two subdomains, Order Management, which has ‘normal’ resource needs, and Fraud Detection, which needs GPUs. To achieve the desired throughput 10 instances of Order Management are required but only 5 instance of Fraud Detection is required If we put these two subdomains in the same Order Service component, we will have to provision 10 instances of the component, which will result in 5 instances of Fraud Detection being underutilized. This architecture might be expensive to scale since p4d.24xlarge EC2 instances that have GPUs are 8x the price of m5.24xlarge instances. We can reduce the cost of scaling by segregating these two subdomains into separate services, which can be scaled independently.

Segregating subdomains by their resource requirements is mostly beneficial when operating at high scale when there are significant cost savings.

Segregating by regulations to accelerate development

Software development in some domains is regulated. For example, if you are developing software that’s classified as Software as a Medical Device then your development practices follow various standards such as ISO 13485 and ISO/IEC 62304, which are obstacles to DevOps-style development. However, it’s possible that only a subset of your application’s subdomains are regulated. If that’s the case, then you can segregate the regulated subdomains into separate service(s). This will enable you to develop the unregulated subdomains using DevOps practices.

Segregate by business criticality to improve availability

It’s likely that some of your application’s subdomains are more business critical than others. For example, let’s imagine that you are credit card payment processing company. The subdomains that handle credit card authorization and charge requests are critical to the business. That’s how you make money and you most likely have strict SLAs with your customers. In contrast, other subdomains, such as merchant account management, are likely to be less critical.

You can, therefore, improve availability by segregating subdomains by the business criticality. You can, for example, define a Payment Service, which handles credit card authorization and charge requests. It has a separate code base, runs on its own infrastructure and is decoupled at runtime from the rest of the services. As a result, it’s unaffected by any problems that might occur in the rest of the application. Moreover, developers working on other functionality, such as merchant account management, don’t have to worry about breaking the Payment Service.

Segregating by business criticality is typically beneficial when there are severe consequences of downtime, e.g. violating an SLA.

Segregate to improve security

Some subdomains manage sensitive data, such as Personally Identifiable Information (PII). Packaging such a subdomain as a separate service can improve security. The data can only be accessed via the service’s API. Moreover, network-level security mechanisms can be used to further restrict access.

Segregating by DDD subdomain type to accelerate development

In Domain-Driven Design (DDD), subdomains are classified into the following types:

  • Core - the business logic that’s unique to your business and provides competitive advantage. Core subdomains should be the focus on your development efforts.
  • Supporting - the business logic that’s common to many businesses but often requires customization. Ideally, you should be able to buy this functionality from a third party but sometimes you must write it yourself.
  • Generic - the business logic that’s common to many businesses but doesn’t require customization. Generic subdomains should be bought from third parties.

We can improve productivity by packaging core subdomains as services that are separate from those non-core subdomains. This ensures that their development is no longer affected by or constrained by those other subdomains. You could, for example, upgrade or change a core domain’s technology stack separately from any non-core domain. Packaging core subdomains separately increases the organization’s ability to focus on their development.


microservice architecture   architecting   dark energy and dark matter  


Copyright © 2024 Chris Richardson • All rights reserved • Supported by Kong.

About Microservices.io

Microservices.io is brought to you by Chris Richardson. Experienced software architect, author of POJOs in Action, the creator of the original CloudFoundry.com, and the author of Microservices patterns.

Upcoming public workshops: Microservices and architecting for fast flow

In-person: Berlin and Milan

DevOps and Team topologies are vital for delivering the fast flow of changes that modern businesses need.

But they are insufficient. You also need an application architecture that supports fast, sustainable flow.

Learn more and register for one of my upcoming public workshops in November.

NEED HELP?

I help organizations improve agility and competitiveness through better software architecture.

Learn more about my consulting engagements, and training workshops.

LEARN about microservices

Chris offers numerous other resources for learning the microservice architecture.

Get the book: Microservices Patterns

Read Chris Richardson's book:

Example microservices applications

Want to see an example? Check out Chris Richardson's example applications. See code

Virtual bootcamp: Distributed data patterns in a microservice architecture

My virtual bootcamp, distributed data patterns in a microservice architecture, is now open for enrollment!

It covers the key distributed data management patterns including Saga, API Composition, and CQRS.

It consists of video lectures, code labs, and a weekly ask-me-anything video conference repeated in multiple timezones.

The regular price is $395/person but use coupon CCMHVSFB to sign up for $95 (valid until November 8th, 2024). There are deeper discounts for buying multiple seats.

Learn more

Learn how to create a service template and microservice chassis

Take a look at my Manning LiveProject that teaches you how to develop a service template and microservice chassis.

Signup for the newsletter


BUILD microservices

Ready to start using the microservice architecture?

Consulting services

Engage Chris to create a microservices adoption roadmap and help you define your microservice architecture,


The Eventuate platform

Use the Eventuate.io platform to tackle distributed data management challenges in your microservices architecture.

Eventuate is Chris's latest startup. It makes it easy to use the Saga pattern to manage transactions and the CQRS pattern to implement queries.


Join the microservices google group