A green coding pattern is a reusable, high-level response to a recurring sustainability problem in software. It reduces unnecessary computation, memory use, storage, network traffic, or hardware demand, lowering both operational cost and environmental impact. The guiding idea is the same as efficient code: avoid work and resources that do not create value. section 1.1.6 section 8.0
These patterns act on two main levers: reduce electricity consumption and limit hardware use and replacement. Code-level changes give developers direct influence, while choices such as efficient data-center cooling, scalable architecture, and demand-based provisioning complement them. section 8.4 section 8.6
Use the pattern that matches the waste being created:
- Frugality: build only features and technical elements that provide real user or client value. section 8.6
- Lean packaging: remove unused dependencies and dead code so artifacts are smaller to store and transfer. section 8.6
- Lean storage: retain only needed data, use efficient formats, and regularly delete operational waste. section 8.6
- Lean communication: reduce request frequency, cache appropriately, and shrink payloads. section 8.6
- Efficient execution: choose better algorithms and smooth workloads to avoid needless CPU work. section 8.6
- Memory efficiency: select lightweight structures and prevent caches from growing without control. section 8.6
Delay a heavy report until the grid is cleaner
A daily report may require substantial processing but not need to run at one fixed hour. Retrieve predicted carbon-intensity values, select the lowest-emission window, and enforce a maximum delay so the report still runs each day. The output stays the same; only the execution time changes. This works best for deferrable work such as analytics, exports, and data processing, not for tasks with immediate user-facing deadlines. section 8.4.7
Treat patterns as design reasoning rather than a universal checklist. Some waste is visible in code or configuration—unused libraries, oversized payloads, inefficient queries, unbounded caches, or loading whole datasets into memory. Frugality and carbon-aware decisions also require product and business context, because value, deadlines, and deployment options determine what can safely change. section 8.5.2 section 8.5.2
Measure targeted problems before and after changing them. CPU and heap profilers, IDE profiling features, and Java Object Layout can reveal bottlenecks and actual object footprints, but their setup, overhead, and diagnostic output make them better for focused investigations than daily use. Footprint estimates become more reliable after deployment through cloud dashboards or installed monitoring. section 8.5.2 section 8.6
Table 8.1 The seven green design patterns
|
Pattern
|
Problem
|
Solution
|
|---|---|---|
|
Frugality
|
Unused features and overengineered architectures waste CPU, memory, and development effort.
|
Build only what provides real value and keep features and technical choices minimal.
|
|
Lean packaging
|
Packages become bloated with unused dependencies and dead code.
|
Remove unnecessary libraries and code to produce smaller, lighter artifacts.
|
|
Lean storage
|
Systems accumulate too much data and operational waste.
|
Store only the data needed, use efficient formats, and delete accumulated waste regularly.
|
|
Lean communication
|
Systems perform excessive network calls with large payloads.
|
Reduce request frequency, use caching, and minimize payload size.
|
|
Efficient execution
|
Inefficient or careless logic forces the system to perform unnecessary computation.
|
Use better algorithms and smooth workloads.
|
|
Memory efficiency
|
Applications retain more data in memory than required.
|
Hold only the data the system actively needs, release resources promptly, and use lightweight structures.
|
|
Carbon aware
|
Tasks run when or where electricity is most carbon-intensive.
|
Shift work to cleaner times or regions and adjust capability based on grid intensity.
|
Compare each pattern’s recurring waste problem with its general solution when selecting an intervention. section 8.4.7
