Build EcoFriendly APIs to Save the Planet And Some Energy Bills Too

Image by PIRO from Pixabay

Muhammad Sajid and Bjorn Eriksen work as solution architects at Amazon Web Services in Stockholm. The trend has been clear since 1971. We’ve gone from consuming 1 Earth to consuming 1.75 Earths per year. In this article, Muhammad Sajid and Bjorn Eriksen discuss how developers and builders can contribute to lowering carbon dioxide usage by architecting for sustainability.

July 28, 2022, was World Overshoot Day. This day marks when we have used all the biological resources that the Earth can regenerate in the entire year. In April 2023, in Sweden, we passed the Overshoot Day for 2023. This means that if the world consumed in the same way as in Sweden, we would have already used all the biological resources that the Earth regenerates in one year in April. Pakistan does not have an overshoot day. Pakistan is a country that uses fewer biological resources. With their consumption pattern, we would be in a much better shape. We have huge inequalities in the world. The way we consume in the West is having environmental consequences in other places of the world.

Let’s be honest: we will not save the world by changing the API design. We can only make a real impact by changing how we consume. There is a shared responsibility between publishers and consumers of APIs. It is a shared responsibility between the two to lower the CO2 impact of an API call. But if the publisher of an API does not create the levers for the consumers to use, then this shared responsibility becomes a wall of separation.

Let us consider an analogy. In the EU, road transport accounts for about 1/5 of all the CO2 emissions, and passenger cars are a major polluter. They account for 61% of the CO2 emissions from EU road transports. When you drive a car, you sometimes need access to the engine’s full power. But other times, speed and response time are not the priority, and you can choose to put your car into Eco mode. So, let us take this Eco mode to APIs.

Back in 2021, web traffic exceeded 2.8 zettabytes. In 2.8 zettabytes, you can store 21 trillion mp3 songs; one would need to be alive 490 million years to listen to all those songs. And most of this traffic is going through or was going through APIs. So, as API developers, we have a huge opportunity to make our APIs carbon-efficient. Three activities can reduce the carbon emission of an API or any software –

  • Energy efficiency is consuming the least electricity to run our APIs or other software.
  • Carbon awareness means doing more when the electricity is clean and less when using fossil fuels.
  • Hardware efficiency involves reducing embedded carbon in hardware where our APIs or any software is running. Embedded carbon is the total greenhouse gas emissions generated during the production and disposal of a device, hardware, or server on which we run our API.

To make our APIs eco-friendly, we must ensure we host them in a region powered by clean energy. Most public cloud vendors are investing a lot in creating sustainable data centers. To run APIs in an eco-friendly manner, we have to focus on at least three aspects –

Network optimization can be done by reducing the network traffic by your API by keeping the data closer to your API consumers. For example, if you use microservices architecture and two or more micro-services are highly coupled, consider co-locating them to reduce network congestion and latency. This will also reduce the cost of your API. We can also reduce the amount of data we transfer between two services. Similarly, we can use caching mechanisms whenever possible and energy-efficient protocols like MQTT.

Increase computer utilization by right-sizing the infrastructure required to run your APIs. You can destroy or completely turn off non-production environments after use. You can easily re-create the environment that you destroy. Consider delaying asynchronous background processes to run when the compute resources are idle. You should also consider running any resource-intensive workload in the region with lower carbon intensity. You should also think about performing compute-demanding tasks in the cloud.

Storage or database optimization can be done by reducing the amount of data you store and deleting the data you don’t need. If possible, relax the consistency requirements on your databases and embrace eventual consistency. Eventual consistency does not mean a lack of consistency. It means full consistency after a minimal replication lag. Finally, choose energy-efficient file formats to store raw data.

Architecture patterns to reduce energy consumption

  • Queue-based load leveling can be used to process multiple messages in a batch during a low carbon intensity time. For example, you can batch the messages and move the processing to a different time rather than processing them immediately.
  • Event-driven architecture – Prefer event-driven over request-response patterns to avoid blocking the client while awaiting API responses.
  • If you have energy-inefficient legacy systems, isolate them using an anti-corruption layer pattern to avoid spreading inefficiencies in other parts of the system.

Measuring the carbon emission of a software

As Peter Drucker said, if you can’t measure, you can’t improve. What gets measured gets improved. What gets measured and reported back gets improved exponentially. That means we should report the estimated carbon emissions of our APIs back to our API consumers.

Software carbon intensity (SCI) is a method for scoring a software system based on carbon emissions. It’s a methodology for calculating a software system’s carbon emissions rate. In our case, that software system is an API.

SCI = ((E*I)+M) per R

E = energy consumed by the APIs measured in kilowatt-hours.

I = carbon emitted per kilowatt hour of energy, and we measure it in grams of CO2 produced per kilowatt hour.

M = embedded carbon, that is amount of carbon produced during the creation and disposal of a hardware device.

R = This is how your API or any software scales, for example, per user per API call or device.

We need to do something right now. Even if our industry is responsible for just a small percentage of the overall global carbon emissions, we have the opportunity to reduce our emissions and help other industries reduce theirs. We have a responsibility. We do not inherit the Earth from our ancestors. We borrow it from our children.

Muhammad Sajid
Muhammad Sajid is a high-octane cloud solutions architect with a passion for turning whiteboard drawings into fully functional cloud-native software solutions. He speaks regularly at several community and company events and conferences about cloud, architecture and cloud-native software development. Sajid has helped many organizations and individuals in their cloud transformation journey by training and mentoring individuals and teams on modern cloud-native development techniques. He has a great interest in Generative AI, DDD, Distributed Systems, Event-Driven Microservices, and Containerization. His superpowers are mentoring, storytelling, teaching, and leading and building high-performance teams. -Automation freak. -Bad at multitasking. -Big-time browser tabs-hoarder. -Plays badminton and takes photographs.

APIdays | Events | News | Intelligence

Attend APIdays conferences

The Worlds leading API Conferences:

Singapore, Zurich, Helsinki, Amsterdam, San Francisco, Sydney, Barcelona, London, Paris.

Get the API Landscape

The essential 1,000+ companies

Get the API Landscape
Industry Reports

Download our free reports

The State Of Api Documentation: 2017 Edition
  • State of API Documentation
  • The State of Banking APIs
  • GraphQL: all your queries answered
  • APIE Serverless Architecture