Understanding and Mitigating High Energy Consumption in Microservices

The tech industry is shifting toward greener practices, with major companies like Google, Amazon and Meta leading the way. However, the adoption of complex distributed architectures can sometimes run counter to these sustainability goals. Although the industry has been actively transitioning from monolithic to microservices architectures, studies suggest that microservices often consume significantly more CPU, memory and network resources compared to traditional monoliths. Comparative analyses by the Journal of Object Technology and Aalborg University showed that microservice architectures consume approximately 20% more CPU and 44% more energy consumption than monoliths.

Given this challenge, it’s important to identify approaches that make microservices more energy-efficient. This article explores how thoughtful design and operational strategies can help reduce the energy consumption of microservices.

Building Greener Microservices

Microservices are inherently less energy efficient than monoliths due to their distributed nature, often leading to increased network traffic and resource overhead. However, by carefully defining service boundaries and optimizing how services are deployed, organizations can significantly reduce the energy footprint of their microservices architecture. These optimizations fall into two main categories: design-related and operational-related efficiencies.

Design-Related Efficiencies

To optimize energy efficiency in a microservices architecture, defining effective service boundaries is the key. This involves two complementary strategies: 1) encapsulating each domain within a single service to minimize inter-service communication and 2) selecting service granularity not just for scalability, performance and organizational alignment but also with energy efficiency in mind.

Domain Encapsulation

If a single domain is not encapsulated within one service, it inevitably creates tight coupling between services and increases interdependencies. Simple requests may then require coordination across multiple services, resulting in chatty communication patterns and greater overhead for maintaining consistency across distributed data.

Service boundaries that fully encapsulate domains can significantly reduce inter-service calls, decreasing not only network traffic but also the processing power required to handle each additional request. For example, as shown in Figure 1, suppose a user needs to retrieve the car inventory. Since the inventory system is distributed across Services A, B and C, a total of eight service calls are needed to gather all the required information. Similarly, retrieving an order or a payment also requires multiple network calls because the domains are split across different services. However, if each domain were isolated within its own service, these services would not need to call each other for simple queries limited to a single domain, and the number of required calls would be significantly reduced. In this case, retrieving the inventory would now require only two calls, as Service A would not need to call Services B and C.

Figure 1. Well-Defined vs incorrect service boundaries for inter-service calls.

Additionally, if a single domain is not encapsulated within one service, a single request may involve updating tightly coupled data in several different databases. If one service fails to complete its operation successfully, it may be necessary to roll back changes across multiple services to maintain data consistency. Therefore, more CPU and network calls are required to make additional updates across multiple services. Consider the following diagram, which shows how a failure to create data in Service C caused rollbacks across Service A and Service B, requiring additional processing across services.

Figure 2: High network calls to update data of the same domain distributed across services.

This additional overhead for coordinating data modifications and rollbacks is a common challenge across various distributed algorithms such as the Two-Phase Commit, Three-Phase Commit, SAGA patterns, etc. For example, Figure 3 illustrates the SAGA choreography pattern, highlighting how each step in the transaction requires multiple network calls and additional processing across the system.

Figure 3: High network calls in SAGA choreography pattern.

However, if the inventory domain were consolidated within a single service, both updates and rollbacks could be managed through a single database transaction. This allows the database to handle commit or rollback operations atomically, eliminating the need for additional computation or network calls to coordinate these actions across multiple services.

Figure 4. Well-Defined service boundaries for distributed data.

Service Granularity

The granularity of a microservice refers to the scope of responsibility it handles i.e. how many business domains are consolidated within a single service. For instance, Order, Payment and Inventory can each be implemented as individual services or merged into a single, consolidated service.

Figure 5. Consolidated vs Individual Services.

When services are consolidated, inter-service communication is reduced, which lowers both network traffic and processing overhead. However, excessive consolidation risks creating a monolithic application, diminishing the advantages of modular design. The optimal approach is to maintain a balance:

• If business domains are closely interdependent, grouping them within a single service helps minimize communication overhead and simplifies distributed transactions, thereby improving energy efficiency.
• If business domains are logically independent and have minimal interaction, separating them into distinct services enables independent deployment without incurring significant network overhead. This allows for more efficient resource allocation strategies tailored to each service’s workload.

The following steps can help evaluate whether to consolidate or separate services during the architecture design phase:

Step 1: Identify Dependence Level

Map out various scenarios in which the domains interact (e.g., API calls, events, etc.), including failure cases. For example, consider the following sequence diagram that illustrates various interaction scenarios between Order, Inventory and Payment domains.

Figure 6. Sequence diagram representing domain interactions during design phase.

Step 2: Explore Strategies to Minimize Interdependence

Evaluate whether any strategies can be applied to minimize interdependence between domains and thereby reduce energy consumption from network overhead and compute load. Some examples include:

• Caching: Use caching when one domain frequently accesses another’s data to reduce redundant API calls and database queries.
• Data denormalization: Duplicating data across domains can help eliminate real-time dependencies.
• Bulk API calls: Aggregating multiple requests into a single bulk call can help reduce the number of network calls.

For instance, in the example above, multiple payment collection calls were made for a single order. This can be optimized by consolidating them into a single bulk API call.

Figure 7. Sequence diagram representing optimized domain interactions.

Step 3: Re-evaluate Dependence Level

After optimizing for fewer interactions, if domain dependence remains high, consider consolidating them into a single service for reduced network overhead. If dependence is low, keep the domains separate to allow for more flexible deployment. In the example above, if the Order and Inventory domains are highly dependent while Payments is loosely coupled, then Order and Inventory can be combined into a single service, whereas Payments can remain as an independent service.

Figure 8. Consolidating interdependent domains into a single service.

Finding optimal service granularity and interdependence is important for well-architected microservices when considering factors such as performance, scalability, and development teams. It so happens that finding these optimal boundaries usually makes the whole system more energy efficient.

Operational-Related Efficiencies

Location-Based Scheduling

Some data centers are significantly more carbon efficient than others. Their efficiency depends on a variety of factors, including cooling methods, hardware and the source of electricity. Deploying applications on carbon-efficient data centers is generally more sustainable. Many cloud providers provide data on which regions are more carbon efficient. Figure 9. shows how Google releases its data across regions.

Figure 9. Carbon data across Google cloud regions. Source: Google Cloud Website. Accessed: June 14th 2025.

When deploying applications, this data enables more informed and sustainable decisions about regional placement. Because microservices are inherently more granular, they can be strategically deployed to improve overall energy efficiency:

• Latency-sensitive microservices that depend on frequent user interactions should be deployed closer to end users. This minimizes network overhead and improves energy efficiency by reducing data transmission costs.
• Batch-processing microservices, such as analytics pipelines or reporting jobs, can be deployed in carbon efficient regions. These services typically don’t require real-time responses and can take advantage of low-carbon infrastructure.

Figure 10. Location-based deployment based on the type of microservice.

It is important to note that while deploying microservices in carbon-efficient regions can improve sustainability, architectural decisions about location always involve trade-offs related to attributes such as performance, cost and data accessibility. For example, consider a scenario where analytical services are deployed in a carbon-efficient region, and their dependent data sources are colocated for optimal energy efficiency. While this setup may minimize the carbon footprint for the analytics workload, it can introduce higher latency and reduced performance for other services that need to access the same data from different regions. Consequently, architects must evaluate and balance sustainability with other attributes based on the priorities and usage patterns of the system.

Optimized Resource Scaling

When allocating resources to microservices, consider these traffic characteristics:

Bursty

Autoscaling dynamically adjusts resources based on demand changes, scaling up when demand increases and scaling down when it decreases. However, reactive autoscaling may not react quickly enough to sudden traffic spikes, potentially resulting in temporary over or under-provisioning.

Figure 11. Overprovisioning when auto-scaling during traffic spikes.

To handle such spikes in an energy efficient way, consider implementing a queuing mechanism. A queue can be placed at a key entry point service, which will throttle incoming requests and, as a result, slow down request processing across all downstream microservices. This approach trades off immediate performance for improved energy efficiency, as it avoids rapid and potentially excessive scaling. Ultimately, all requests will be processed with some delay, allowing the system to absorb traffic spikes without unnecessary resource allocation.

Figure 12. Resource allocation is constant during a traffic spike.

Non-Critical

The granularity of microservices provides the advantage of allocating resources based on the criticality of individual services. While critical services require guaranteed resources to maintain performance, non-critical tasks can be allocated fewer resources to prioritize energy efficiency. Mechanisms such as batching requests during non-peak hours can help ensure that all requests are processed, while rate limiting can be used to control the service load by rejecting excess requests during peak times.

Figure 13. Resource allocation in non-critical services remains constant even though the load is higher.

Latency-Sensitive

For services where performance is a priority, resources often need to be consistently available and potentially over-provisioned to minimize response times. This approach inherently leads to lower energy efficiency.

Workload Consolidation

To optimize resource allocation, a recommended practice is to maintain average CPU utilization between 50% and 80% across servers. Utilization above 80% can lead to performance degradation due to resource contention and thread starvation, while levels below 50% often indicate underutilized resources. Underutilization is a problem because the “always-on” energy is a sort of infrastructure tax that exists just for having the machine running. If the server performs very little work relative to its energy use, its energy efficiency ratio becomes poor. Think of it as burning fuel to idle at a traffic light – power is consumed, but no progress is made.

In a microservices architecture, services are typically granular and lightweight, meaning they may not fully utilize a node’s capacity. As a result, co-locating multiple services on the same node can improve efficiency and reduce overall energy consumption. For example (as shown in Figure 13), if Services A, B and C consume 20%, 10%, and 25% of CPU respectively and are distributed across multiple nodes, a significant portion of compute capacity remains idle. Consolidating these workloads onto a single node allows for the reduction of the total number of active nodes in the cluster, thereby saving energy by eliminating the idle power consumption of the decommissioned servers. Note: this example has been simplified for illustration. In practice, microservices are typically deployed across multiple nodes to ensure higher availability and fault tolerance.

Containers enable this consolidation by providing lightweight packaging, allowing multiple services to run on the same node without dependency conflicts. Container orchestration platforms such as Kubernetes can automate this process by allowing developers to define the desired output and handle scheduling based on that.

Figure 14. Workload consolidation allowing optimized resource consumption.

Additionally, if a service is only needed for a limited time, turning it off entirely is often the most energy-efficient approach, a practice known as LightswitchOps. However, when services must remain available throughout the day, background scheduling can be employed to further optimize resource usage. For example, consider Services A, B and C, which primarily handle daytime traffic, and a batch-processing Service D that requires 50% CPU but is not time-sensitive. By scheduling Service D to run during off-peak hours on the same nodes as Services A, B, and C, overall resource utilization can be increased. This approach helps maintain average CPU utilization within the ideal range of 50% to 80% without overloading the system resources.

Figure 15. Background scheduling allowing optimized resource consumption.

Conclusion

Even though microservices are inherently more energy-intensive, it is possible to improve their efficiency through thoughtful design choices that reduce unnecessary interdependencies and by deploying them in ways that optimize energy consumption. As microservices continue to dominate software architecture due to advantages like scalability and faster development, it’s essential for developers to treat energy-efficiency as a first class concern. In this way, the advantages of microservices can be leveraged alongside greater sustainability in software systems.