Most people associate green software with saving energy, tuning servers or cutting CO₂ emissions. Many of the decisions that matter, though, are architectural: where code runs, when it runs, how much data it moves and what hardware it needs.
Below are ten techniques worth knowing. None of them is automatically “green”. Each is a trade-off that has to be checked against the whole system.
First, some vocabulary. The Software Carbon Intensity (SCI) specification from the Green Software Foundation sorts actions that reduce software emissions into three categories:
- Energy efficiency: using less electricity for the same function.
- Hardware efficiency: using fewer physical resources for the same function.
- Carbon awareness: shifting computation in time or region to use lower-carbon electricity.
A system can be very energy efficient and still run on a carbon-heavy grid. A carbon-aware scheduler does nothing about the emissions from manufacturing the servers it runs on. Keeping the categories apart shows what a given technique actually changes.
1. Move computation to the user’s device
Does everything have to be processed on the backend? Validation, filtering data the client already has, or simple rendering can run in the browser or on a phone, which reduces round trips and server load.
Less server load is not the same as fewer emissions. The work has crossed a system boundary to devices you don’t control, some old and inefficient, often with a larger download to deliver the logic. The SCI specification lets you include end-user devices in the software boundary, and for this comparison you should. Compare both variants within the same boundary before calling it a win.
2. Follow the Sun (Spatial Shifting)
If a workload can run in several regions, you can send it to the one where electricity currently has the lowest carbon intensity. This is spatial shifting.
The name is misleading: it has nothing to do with where it is daytime. What counts is the actual carbon intensity of the regional grid at that moment. The SCI specification uses location-based grid intensity and excludes market-based instruments such as renewable energy certificates, so a region marketed as “100% renewable” is not necessarily the cleaner choice.
Spatial shifting also costs something: duplicated infrastructure, replicated data, cross-region transfer, and possibly data residency conflicts. Latency-sensitive paths with strict SLOs are poor candidates. Stateless or batch workloads with small inputs are better ones.
3. Compute later (Temporal Shifting)
Does a report needed tomorrow morning have to be generated at 3 p.m. today? If not, schedule it for a window when grid electricity is less carbon intensive. This is temporal shifting.
Good candidates have a deadline but flexible timing: nightly reports, backfills, ML training, index rebuilds. Express the flexibility explicitly, for example as “must finish by” instead of a fixed cron time, and define a fallback when no cleaner window appears before the deadline. Without one, the scheduler becomes a reliability risk.
4. Turn off what you don’t use
It sounds trivial, but how many development and test environments run all night and over the weekend?
Scheduled shutdowns, scale-to-zero and right-sized instance counts are among the cheapest actions available. The SCI specification counts energy for all hardware reserved or provisioned, not only what is actually used, and reserved capacity also carries a share of embodied emissions. The usual costs are cold starts and the person who needs an environment at 11 p.m., so make the schedule easy to override.
5. Don’t move data without a reason
Suppose you hold several terabytes of data in Europe but process it in the United States. The transfer itself uses energy and network equipment.
Sometimes running the computation close to the data is the better option, even if another region has a cleaner grid. Here spatial shifting and data gravity pull in opposite directions. The same applies on a smaller scale: chatty service calls, full exports where an incremental sync would do, and pipelines that copy the same dataset into several stores. Filter at the source and question every copy.
6. Let hardware live longer
Manufacturing servers, laptops and phones produces emissions. The SCI specification calls these embodied emissions and allocates a share to software based on how much of a device it reserves and for how long, amortized over the device’s expected lifespan.
If every release needs more memory and CPU, we push people toward replacing devices sooner. Controlling memory and CPU footprints and supporting older devices and browsers for longer helps extend hardware life. On servers, higher utilization of fewer machines usually beats many half-empty ones.
7. Design interfaces that don’t waste resources
Do all images need to load at once? Does the app have to poll the backend every second? Do we need autoplaying video?
Lazy loading, caching, correctly sized images, and replacing tight polling with push or longer intervals reduce work on the client, the network and the server. A lighter page also loads faster on a weak connection or an old phone. Look at the whole path, though: a cache that serves stale data and triggers manual refreshes may save nothing.
8. Don’t use a huge AI model for everything
For simple text classification, a small model or a conventional algorithm may be enough. A routing layer can match the model to the task and escalate only when needed.
Model size on its own is not an energy metric. A smaller model that makes more errors, needs retries, produces longer outputs or requires human correction may cost more overall than a larger one that gets it right the first time. Compare task quality, tokens per request, retry and fallback rates, and the hardware the model runs on, and measure per completed task, not per call.
9. Optimize CI/CD
Every build, test and runner uses energy, and the SCI specification lists build and deploy pipelines and testing inside the software boundary. In large organizations the volume adds up.
Use dependency and build caching, skip builds for changes that cannot affect an artifact, cancel superseded runs, and run only the tests affected by a change. Test selection needs safeguards, because selection logic misses dependencies and an escaped regression costs more than the saved compute. Keep full runs on a schedule and before releases, and track escaped defects to tune the selection.
10. Adapt service quality to clean energy availability
Imagine a system that, when grid carbon intensity is high, recalculates recommendations less often, limits analytical jobs or postpones data synchronization. This is demand shaping, and it makes the system carbon-aware in the SCI sense: it adjusts its behavior to the carbon intensity of the energy it consumes.
The condition is that critical business functions are unaffected. Decide up front which features may degrade. Payments, safety-relevant features and essential user tasks may not. Accessibility may not either: someone using a screen reader or a slow connection must not lose access. Document the degraded modes, test them like failure modes, and keep them within agreed SLOs.
Sustainability as a quality attribute
As architects, we design for performance, availability, security and cost. Sustainability belongs on that list as another quality attribute, and that is when the trade-offs get interesting. Is higher latency acceptable to reduce emissions? Is multi-region infrastructure greener once you count duplicated resources and replication traffic? Are microservices justified when you include infrastructure that runs all the time?
There is no single answer. You have to measure, compare and decide deliberately. The SCI specification provides a structure: emissions as a rate, operational plus embodied, per functional unit such as an API call, transaction, user or batch job. The unit matters, because total emissions can rise as a product grows while emissions per transaction fall. Comparisons must use a baseline built with the same method, boundary and functional unit, and offsets or certificates cannot reduce the score. Only eliminated emissions count.
A short starting checklist
- Draw the boundary: compute, storage, network, CI/CD, monitoring, backups, failover capacity and, where relevant, end-user devices.
- Pick a functional unit that reflects how the system scales.
- Establish a baseline before changing anything. Modelled estimates are acceptable where measured data is unavailable.
- Classify each idea as energy efficiency, hardware efficiency or carbon awareness.
- Check for displacement: does the change reduce emissions, or move them to clients, regions or the network?
- Write down the constraints: SLOs, data residency, critical functions and accessibility.
- Start with idle resources and CI/CD. They are usually the cheapest to fix and the easiest to measure.
- Re-measure with the same method and track the result next to your other quality metrics.