::: making things abstract This research does an extensive assessment and juxtaposition of Software Carbon Intensity (SCI) for seven modern backend frameworks: Java Spring Boot, Java Quarkus, Go Gin, Rust Axum, and Python FastAPI JavaScript Express and C# .NET. In the time of huge digital The choice of backend technology has an effect on more than only the functioning of the application and the digital carbon footprint that comes from it. We use a controlled experimental method to detect energy The amount of energy used, the time it takes to respond, the amount of memory used, and the amount of carbon dioxide released by each framework while doing the same CRUD activities. The results show big variations in how energy-efficient: compiled native languages Compared to interpreted languages, Rust and Go are 40–60% more efficient. languages like Python and JavaScript, as well as VM-based languages with JIT Compilers like Java and C# are in the middle. This study offers empirical advise based on evidence for industry professionals that want to embrace Green Coding methods that work to lessen the environmental impact of systems for businesses. :::

Introduction

Background and Reason for Doing It

Climate change has become one of the most important problems for people to solve. in the 21st century, thanks to the Information and Communication Technology The ICT sector is becoming more and more important. Estimates right now show that the ICT industry makes up about 1.8% to 3.9% of a number that is similar to the aviation industry's greenhouse gas emissions. business [@Freitag2021]. This contribution is expected to becoming bigger. a lot as digital transformation speeds up in all areas of the world's economy.

The rapid expansion of cloud computing and microservices architectures and API-driven apps have made backend services more in demand than ever. Services. Data centers all throughout the world work around the clock to service these services, using a lot of electricity and making a lot of carbon emissions. In this situation, the decision of programming Languages and frameworks for backend development become more than just a a technological choice, but also a necessity for the environment [@Koenig2020; @Wasif2024].

Green Software Engineering (GSE) has become an important field to make software systems that use less energy and sustainable for the environment [@Ardito2015]. A key measure in GSE is Software Carbon Intensity (SCI), which measures the carbon the amount of emissions produced for each functional unit of software operation. Even though Earlier studies have investigated algorithmic optimization for energy. efficiency within individual programming languages (GSE Type 1 at the algorithmic level) [@Karisma2026; @Lannelongue2021], thorough comparison research analyzing the impact of various backend frameworks on There are still not many SCI values in real business workloads. This research applies GSE Type 1 concepts to the level of framework selection, assessing the natural differences in efficiency between seven modern technology stacks running the same business logic.

The Problem of Choosing Technology

Modern businesses commonly use backend technologies based on mainly based on things like how well the developer knows the ecosystem, or how popular it is in the community, without thinking about the long-term effects on the environment [@GreenAdoption2024]. This method doesn't take into account the big disparities in how much energy different programming paradigms use paradigms:

• Interpreted Languages: Python and JavaScript (Node.js) are the most popular. current development because of the ability to quickly prototype and lots of books. But their runtime interpretation overhead frequently leads to greater energy usage than compiled other options [@Pereira2017; @PythonMicroscope2025; @vanKempen2024].

• Compiled Native Languages: Languages like Rust and Go that are based on come from the C/C++ family and compile directly to machine code with minimal overhead at runtime. Rust's memory management based on ownership supposedly eliminates the need for waste pickup, offering better energy efficiency [@RustOwnership2023].

• Virtual Machine (VM) Based Languages: Java and C# run on advanced virtual machines (JVM and CLR, respectively) that use Compilation that happens just in time (JIT). These platforms are portable. and ecosystems that are already well-developed, but they add memory management overhead. different methods for collecting waste [@JavaJIT2024; @DotNetCLR2024].

What We Want to Find Out and Why

Even if more people are learning about the fundamentals of Green Software Engineering, There are still some important knowledge gaps:

1. Comprehensive Framework Comparison: The majority of current studies concentrate on comparisons at the language level using benchmark programs instead of realistic workloads for applications [@Pereira2017; @ProgrammingRank2024].

2. Per-Endpoint Analysis: There is not much study on energy consumption at the level of individual API endpoints (CRUD operations), which is necessary for finding ways to improve chances.

3. Positive vs. Negative Cases: The effect of error management on energy and validation (negative test cases) in contrast to successful operations The exploration of good cases remains unaddressed.

4. Effect on Startup Time: The energy use of an application when it first starts up, important for serverless and containerized deployments, is not often quantified.

This research fills these voids by doing actual measurements of SCI across seven contemporary backend frameworks exemplifying diverse paradigms for runtime. We not only look at total energy use but also Also, metrics per request, startup overhead, and profiling at the function level to find places where energy is high.

Contributions to Research

This study adds to the field of Green in the following ways: Engineering for Software:

1. 1. Comprehensive Empirical Data: Thorough assessments of energy memory utilization, carbon emissions, response time, and power usage spans seven production-ready backend frameworks that all do the same thing business rules.

2. Per-Endpoint Granularity: A detailed look into CRUD activities like Create, Read, Update, and Delete for more than one domain entities (Users, Addresses, Carbon Credits, Trees Donations).

3. Positive and Negative Case Analysis: Energy comparison utilization between successful operations and error handling situations.

4. Practical Recommendations: Software advice based on data architects choosing technology for businesses that will last systems.

5. 5. Open Dataset: All of the experimental data, measurement scripts, and analyzing tools that the research community can use to check their work and an extension.

The rest of this paper is set up like this: Section 2 shows theoretical foundation of Green Software Engineering and programming language traits; Section 3 goes into more information about our experiment technique; Section 4 shows full results; Section 5 talks about the results and their effects; and Section 6 ends with future Directions for research.

Theoretical Background and Related Work

Principles of Green Software Engineering

Green Software Engineering is a discipline that deals with the important necessity to lower the environmental impact of computer systems over their full development and operational life cycle [@Ardito2015; @Koenig2020]. This new field is based on three basic ideas that are connected:

1. 1. Energy Efficiency: Using less electricity needed for software to work, which cuts down on carbon dioxide pollution that comes from using electricity while the computer is running.

2. Hardware Efficiency: Making the most of the hardware you already have computational infrastructure with better software design, It lowers the need for more physical hardware deployment.

3. Carbon Awareness: Knowing about grid electricity carbon intensity into decisions about how to schedule computations, which Workloads can run when renewable energy sources are in charge of the power blend.

The basic truth about computing is that every command to the processor uses electricity, and this use of electricity means carbon emissions depend on how the electricity was made [@Pathania2024]. So, making software that works well that lessens the number of processing cycles, cuts down on memory allocation overhead, and optimizes input/output activities is a direct approach to lessening the influence on the environment.

Green Software Engineering Taxonomy: GSE Type 1 and Type 2

Recent academic research has developed a conceptual taxonomy for putting software's relationship with environmental sustainability into groups, differentiating between two essential methodologies for green computing [@Karisma2026]:

• GSE kind 1 (Green in Software Engineering): This is the first kind talks about how efficient software systems are on their own, with a focus on the lessening of the use of computing resources through improvement of architecture and algorithms. The main goal focuses on improving performance traits that directly translate to less energy use and a smaller carbon imprint. Algorithmic complexity is one example of an intervention. cutting down (for example, $O(n^2) \rightarrow O(n \log n)$), inquiry improving database systems, reducing memory usage, and increases to the efficiency of the execution path.

• GSE Type 2 (Green by Software Engineering): This is a type of covers programs that were made just to help and keep an eye on sustainability efforts in both businesses and society as a whole. Instead of Instead of making the software use its own resources more efficiently, these systems work as tools to help the environment goals like carbon neutrality, following ESG rules, and climate action. Emission monitoring platforms are common examples. methods for managing the grid for renewable energy, sustainability metrics dashboards and methods for keeping track of carbon emissions.

These two groups are different but work well together: Type 1 focuses on the direct environmental costs of running software. Type 2, on the other hand, uses software features to make and speed up efforts to make the outside world more sustainable.

The current study focuses solely on GSE Type 1 issues, examining the impact of technology stack selection—particularly the The architecture of the programming language runtime and web framework has an effect on the basic energy efficiency of a backend that works the same way systems. Previous Type 1 research investigates algorithmic optimization. prospects inside a single linguistic environment [@Karisma2026], our contribution provide cross-language energy measures that can be compared at the framework layer, which helps businesses make decisions about their architecture creating applications.

SCI, or Software Carbon Intensity

The Green Software Foundation came up with the Software Carbon Intensity metric. Foundation offers a defined method for measuring software. carbon emissions. The basic SCI formula is:

$$SCI = \frac{(E \times I) + M}{R} \label{eq:sci}$$

Where:

– $E$ = the amount of energy the software system uses (kWh)

• $I$ is the carbon intensity of the power grid in the area (gCO2eq/kWh)

• $M$ = the amount of carbon emissions that are built into making hardware

– $R$ = functional unit (for example, per API request or per user session)

This study largely examines operational efficiency. The embodied carbon $M$ stays the same across all of them, therefore $(E \times I)$ is the same. experiments utilizing same hardware infrastructure. The carbon in the area The global average for intensity $I$ is 475 gCO2eq/kWh. from the source material [@Lannelongue2021].

Energy Efficiency of Programming Languages

Recent research has thoroughly examined energy use across languages for programming. Pereira et al. [@Pereira2017] did groundbreaking research that looks at 27 programming languages across 10 benchmarks difficulties, discovering that compiled languages such as C, C++, and Rust consistently did better than interpreted languages by a range of 2x to 75x when it comes to how much energy it uses.

More recent research has given us more information:

• Language Rankings: New rankings based on energy readings confirm that compiled native languages (C, C++, Rust, Go) are at the top for energy efficiency, while interpreted languages are the best for energy efficiency, while translated languages (Python, Ruby, Perl) use a lot more energy. [@ProgrammingRank2024].

• Python-Specific Analysis: A close look at Python Execution methods show that the CPython interpreter adds overhead. adds a lot to energy use, together with PyPy (JIT) and Cython (compiled) giving enhancements [@PythonMicroscope2025].

— Green AI Perspective: Looking at machine learning workloads shows that choosing the right language has a big effect on the The carbon burden of training and using AI models [@Marini2024].

Features of the Backend Framework

This study analyzes seven frameworks that embody three unique runtime environments. types of architecture:

Compiled Native Languages

Go (Gin Framework): Google made Go, which is a statically typed language. a compiled language made for writing programs that run at the same time. Important Some of its traits are:

• Lineage: Comes from the C family and is compiled into native machine code.

• Memory Management: A garbage collector that marks and sweeps at the same time optimized for reduced latency [@GoGC2023]

• Concurrency: Lightweight goroutines make it easy to handle requests at the same time

• Performance Profile: Starts up quickly and uses little memory. performance that can be counted on

Rust (Axum Framework): Rust focuses on memory safety without garbage collecting through its ownership system [@RustOwnership2023]. Some of the traits are:

• Lineage: A programming language for systems that was influenced by C++. compiled into native code

• Memory Management: Checking ownership at compile time gets rid of GC overhead at runtime

• Safety Guarantees: Stops frequent memory mistakes like null pointers, data races at compile time

• Performance Profile: Similar to C/C++, no cost abstractions, low runtime

JIT Compilation in a Virtual Machine

Java (Spring Boot and Quarkus): The Java Virtual Machine runs Java. Machine (JVM) with advanced Just-In-Time compilation:

• Lineage: Object-oriented language with a mature environment (25+ years)

• Memory Management: Generational trash collection with more than one algorithms for collecting [@JavaJIT2024]

• JIT Compilation: The HotSpot compiler makes code that is run often run faster. code routes when the program is running

• Spring Boot: A traditional JVM framework with a lot of features set of features

• Quarkus: A modern framework that works best with containers and supports native compilation with GraalVM

C# (.NET): Runs on the Common Language Runtime (CLR) with sophisticated JIT compilation:

• Lineage: Made to blend the speed of C++ with the look and feel of Java memory that is managed

• Memory Management: Generational GC for both workstations and servers modes [@DotNetCLR2024]

• JIT Compilation: The RyuJIT compiler has layered compilation for best performance

• Performance Profile: Works well with Java and has a contemporary runtime architecture

Interpreted/JIT Hybrid Languages

Python (FastAPI): Python is a dynamically typed language that is mostly understood:

• Lineage: A high-level language that puts developer efficiency first

• Execution Model: CPython interpreter with a little amount of JIT improvement

• Memory Management: Cycle-detecting GC with reference counting

• Performance Profile: slower execution but faster development [@PythonMicroscope2025]

JavaScript (Express.js): The V8 engine runs it with advanced JIT compilation:

• Lineage: It started as browser scripting and is now everywhere. Node.js

• Execution Model: the TurboFan JIT compiler and the V8 engine

• Memory Management: collecting junk from different generations

• Event Loop: A single-threaded, event-driven architecture for input and output operations

Related Work on Measuring Energy

There are a few different ways to measure how much energy software uses:

• Hardware Instrumentation: Using power meters and other specialized tools Sensors give precise readings, but they need to be physically accessible. to infrastructure [@Chowdhury2018].

• RAPL Interface: Intel's Running Average Power Limit (RAPL) gives the CPU package's power use using model-specific registers, giving processor-bound workloads a lot of accuracy.

• Software Estimation Models: CodeCarbon and other tools like it GreenScaler figures out how much energy a device uses based on its hardware. utilization metrics [@CodeCarbon; @Chowdhury2018].

Recent research has emphasized the significance of evaluating the full The energy footprint of the software development lifecycle [@Rahman2022] and working together to manage green business processes [Jakobi2016].

Methodology

This study utilizes a controlled experimental approach to guarantee equity. comparison of seven technological stacks. Each framework runs the same business logic and the same functional needs.

Design of the Experiment

Our experimental design employs a methodical framework for measurement and compare the energy efficiency of seven backend frameworks under under regulated settings. The investigation utilizes a between-subjects design. When each framework signifies a distinct treatment group, removing biases and learning effects that could happen in within-subjects designs.

The experimental setup guarantees internal validity by rigorous control of confounding variables: all frameworks work with the same hardware, do the same work, and talk to the same database setting up. Implementing a external validity is how you deal with it. a realistic e-commerce app with business logic that makes sense (user management, handling addresses, carbon credit transactions, and tree tracking contributions), which makes the results applicable to comparable systems for making things.

To make sure that each test case is reliable, it is run several times. in a variety of execution settings (both positive and bad), Statistical approaches are used to combine the measurements. The The experimental approach is completely mechanized and recorded, making it possible for full reproducibility by researchers who aren't affiliated with the original study.

The research design adheres to the Goal-Question-Metric (GQM) framework. [@Basili1994GQM]: Our goal is to assess energy efficiency; our Questions ask which framework uses the least energy, works the best, and produces the least carbon emissions. performance, and lowest carbon emissions; our metrics include CPU, memory utilization (MB), reaction time (ms), and energy use (kWh) Use (%), carbon emissions (gCO2eq), and startup time (seconds).

Variables for Research

Table 1{reference-type="ref reference="tab:research-variables"} gives a full picture of all the research factors used in this study. The matrix sorts 19 variables into three groups: independent variables (7 technology stacks), dependent variables (six measures of performance and sustainability), and control variables (6 environmental constants), with matching operational definitions and ways to measure each one.

::: {#tab:research-variables} Type Variable Operational Definition Measurement

---

Independent Variables (Choosing a Technology Stack)
IV-1 Java Spring Boot 3.2: A traditional JVM framework with a lot of capabilities. Framework selection IV-2 Java Quarkus 3.6: A cloud-native JVM framework that works best in containers. IV-3 Go Gin 1.9 Compiled native with HTTP web framework Framework selection IV-4 Rust Axum 0.7 Compiled native with async web framework Framework selection IV-5 Python FastAPI 0.104: An asynchronous ASGI framework for Python 3.12. Framework selection IV-6 JavaScript Express 4.18 Node.js web application framework Framework selection IV-7 C# .NET 6.0 CLR-based framework with RyuJIT compiler Framework selection Dependent Variables (Metrics for Performance and Sustainability)
DV-1 Energy Usage: The amount of electrical power used during execution (kWh) via Intel RAPL MSR registers DV-2 Response Time Time between request and response (ms) Application timestamps DV-3 Memory Usage Peak and average RAM utilization (MB) Docker Stats API DV-4 CPU Utilization Percentage of CPU cycles used (%) Docker Stats API DV-5 Carbon Emissions: CO2eq emissions from energy (gCO2eq) = E × 475 gCO2/kWh DV-6: Startup Time: The time it takes for a container to start and pass a health check (s) and the time stamps for the containers Control Variables (Constants in the Environment)
CV-1 Database System: PostgreSQL 15.0 with the same schema and a fixed configuration CV-2 Hardware: Intel Core i7-1270P (12 cores, max 4.8 GHz), RAPL-enabled Physical machine OS Environment: Ubuntu 22.04 LTS (Jammy Jellyfish) System environment Container Runtime: Docker 24.0.6 with containerd Containerization CV-5 Resource Limits: 2 CPU cores, 2GB of RAM, and no swap. These are Docker limits. CV-6 Network Localhost bridge (no external latency) Docker networking

: Matrix of Research Variables :::

How to Build an Application

The following is the same RESTful API for each framework: Features:

• Domain Model: There are four entities: User, Address, CarbonCredit, and TreeContribution) that have relationships

• Business Logic: CRUD operations, validation, and authentication searches for aggregation

• Database Operations: Connection pooling, prepared statements, managing transactions

• Validation: the format of Indonesian phone numbers and postal codes validation, email validation

• Security: BCrypt password hashing and cleaning up input

All implementations follow SOLID principles and best practices for their their own ecosystems.

Infrastructure for Measurement

Table 2{reference-type="ref" reference="tab:measurement-tools"} talks about the equipment used to measure and their particular roles used in this research. The infrastructure combines Intel RAPL for monitoring energy at the hardware level with containerization metrics (Docker Stats), configurable performance logging, and stack-specific profiling tools to get a full picture of performance and sustainability information.

:: {#tab:measurement-tools} Category Tool Function

---

Energy RAPL CPU package power use Memory Docker Stats Container memory consumption Performance, Custom Logger, and measuring response time Load Generation, Custom Script, and Concurrent Request Simulation Profiling: Function-level analysis for certain stacks

: Tools and Functions for Measurement ::

How the Experiment Worked

The experimental approach adheres to a structured six-phase workflow. made to make sure that all measurements are the same and can be repeated sets of technology. All frameworks go through the same tests. with automated orchestration removing the need for human control, human bias and changes in time.

The first step in the workflow is to check the environment to make sure RAPL energy access to measurement, availability of Docker infrastructure, and database connectivity. After successful validation, each framework's The container image is produced and deployed with standardized resources. limits (2 CPU cores and 2GB of RAM). A baseline after deployment The measurement phase sets the amount of idle resources that are being used, which gives reference points for figuring out the resource deltas for each request.

The core testing phase runs all 15 CRUD endpoints in a planned way. provides both good and bad test cases. Energy usage is recorded in microseconds using Intel RAPL registers, while Response times, memory consumption, and CPU usage are recorded through Docker Stats API. Each request has information about what happened before and after it was executed. measures to find out how much energy each process uses.

After endpoint testing, measurements are combined and carbon emissions computed using the global average grid carbon intensity (475 gCO2eq/kWh). After that, the container is taken apart and the volumes are cleaned. make sure the following stack has a clean place to work. After all seven stacks full testing, statistical analysis and visualization across stacks generation yields comparative outcomes.

Figure 1{reference-type="ref"} shows this full workflow. reference="fig:experiment-flow"} shows this full workflow, indicating the order of execution, decision points, and iteration structure that processes all seven technology stacks in the same way ways to measure.