Energy efficient architecture

1) Basic principles

1. Energy as a First-Class Metric. Joules/request, W/core, kWh/TB-month - the same KPIs as p95 and cost.
2. Carbon-/Energy-Aware Orchestration. The load schedule and the placement of tasks take into account the CO₂ intensity of the network and data centers.
3. Data Minimization. Less data → less CPU/IO → less power and cooling.
4. Right-sizing & Right-placing. We select the correct type and size of the resource and place it closer to the user/data.
5. Simplicity Wins. Extra abstraction and chatiness = extra energy.

2) Metrics and models

2. 1 Infrastructural

PUE (Power Usage Efficiency): 'PUE = Total Data Center Energy/IT Load Energy' (the closer to 1, the better).
CUE (Carbon Usage Effectiveness): 'CUE = CO₂e/Energy IT'.
WUE (Water UE): liters of water per kWh - important for regions with water scarcity.

2. 2 Applied

J/req: 'E _ req = ∫ P (t) dt/ N_req'.
kWh/ETL job, kWh/million messages, kWh/model training.
SO₂e/ficha or SO₂e/polzovatel: 'CO₂e = kWh × grid_factor (time, region)'.

2. 3 Carbon model

carbon(req) = energy(req) grid_emission_factor(region, time)
energy(req) = cpu_j + mem_j + io_j + net_j

Where 'grid _ emission _ factor' varies by hour and region (carbon-aware scheduling).

3) Instrumentation and execution level

CPU architectures: ARM/Graviton/RISC-V often give the best "W/perf" for network and Java/Go loads; the x86 remains strong for high bars and some SIMDs.
GPU/TPU/other accelerators: on ML/vector analytics, they often give the best "J/operation" if batched and kept high utilization.
DVFS and power capping: dynamic frequency reduction and TDP limitation for non-critical tasks.
Sleep mode/auto-blanking: aggressive'idle 'policies for workers and backgrounds.
Memory: NUMA locality and reduced page misses reduce bus and cache energy consumption.

4) Architectural patterns

4. 1 Microservices without chatting

Reduce RPC hops: aggregation gateways, composite endpoints.
gRPC/HTTP/2/3 instead of chatty REST.
Batch + Async: Glue small operations.

4. 2 "Warm" and "cold" ways

For rare, heavy requests - as-needed infrastructure (on-demand, functions/serverless).
Hot paths - long-lived connections and pools.

4. 3 Caching with coalescing

Coalescing requests prevents cache miss storms.
Stale-while-revalidate: we give up the outdated, save a trip to the source.

4. 4 Storage tiring

Hot/Warm/Cold/Archive: NVMe → SSD → object-based delayed → glacier.
Automatic ILM/TTL: less spin/IO → less power.

4. 5 Carbon-Aware Planner

Time-transferable jabs (ETL, analytics, training) - to green hours/regions.
Regional egress roads by kWh and CO₂ - aggregate locally.

python def schedule(job):
windows = get_green_windows(job.region_candidates, next_48h)
pick = argmin(windows, key=lambda w: w.grid_factor job.energy_estimate / w.capacity)
enqueue(job, region=pick.region, start=pick.start)

4. 6 Deduplication and Compression Smarter

Compression saves network/disk, but costs CPU. Apply adaptively: large payloads, low CPU loop.

5) Code and data efficiency

Algorithmics: reduce asymptotics> tuning. Profile hotspots.
Memory allocations: buffer lease, object pools - less GC/energy.
Formats: binary protocols, column formats (Parquet/ORC) for analytics, zipf key distribution should be taken into account when caching.
I/O: packetization, vectorization, asynchronous I/O.
Streaming vs full scans: push-down filters to data source.
Edge functions: pre-aggregation, discarding noise events.

E_req ≈ (cpu_ms W_cpu/ms) + (mem_ms W_mem/ms) +
(io_read_mb W_io/mb + io_write_mb W_io/mb) +
(egress_mb W_net/mb)

6) ML and data: energy patterns

Model architecture: small/specialized models, distillation, quantization (int8/4-bit), sparsity.
Training: batch size ↗ disposal, mixed precision (FP16/BF16), checkpoints, early stop.
Inference: batch + microbatch, compilation (TensorRT/ONNX Runtime), dinam newt server. butching.
Feature and feature story: caching of frequently used features, quality degradation instead of source overload.

7) Network and protocols

Keep-alive, HTTP/3, QUIC, minimizing handshake.
CDN + edge caches: shorter routes → less than kWh.
Compression with profile: zstd/brotley for large resources, no compression for small/CPU-expensive paths.
Multi-regional duplication - only when RTO/RPO is really needed.

8) Telemetry and energy observability

8. 1 Collection

Power/power counters (IPMI/RAPL/Node Exporter power), GPU/TPU telemetry.
At the application level: J/req attribution - via CPU/IO time sampling and calibration factors.
Correlation with traces: 'energy _ j', 'carbon _ g', 'grid _ factor', 'region'.

8. 2 Metrics and alerts

Energy per SLI: `J/p95`, `J/txn`.
Carbon budget: monthly CO₂e limits by product.
Drift: 'J/req' growth> X% of baseline.

9) CI/CD, gates and testing

Perf-smoke + Energy-smoke on PR: short script, collect'J/req' and regress gate.
Energy baselines: store the reference (CPU/GPU, J/req flamegraphs).
Policy as Code: prohibition of deploy, if 'Δ J/req> 10%' without approved exception.
Chaos + energy models: dependency degradation should not raise J/req beyond limits (shading/degradation instead of retray storms).

10) Load and time management

Time shift (load shifting): non-interactive tasks - in "green" hours.
Dynamic SLO: For backgrounds, you can increase latency to save energy.
Prioritization: critical requests receive "energy quotas," low priority - postponed.

python if energy_budget.low() and req.priority == "low":
return 429_DEFER process(req)

11) Security, privacy and compliance

Hardware accelerated encryption (AES-NI/ARMv8 Crypto) - less CPU/W.
PII minimization reduces storage/analytics burden.
Logs: sampling, masking and TTL - saves collection/storage energy.

12) Anti-patterns

Global replication "just in case."

Excessive microservice and "chats" between services.
Zero cache TTLs and stale prohibition.
Full scans without filters/indexes/batches.
Constant retreats without jitter → network storms.
Using the "big model" where the heuristics are enough.

Heavy log formats and "log everything forever."

13) Mini recipes and examples

13. 1 Adaptive response compression

python def maybe_compress(resp, cpu_load, size):
if size > 641024 and cpu_load < 0.6:
return compress_zstd(resp, level=5)
return resp # мелкие/дорогие по CPU ответы не сжимаем

13. 2 Inference Butching Heuristics

python batch = collect_until(max_items=64, max_wait_ms=8)
result = model.infer(batch) # ↑ утилизация ускорителя, ↓ Дж/запрос

13. 3 ILM/TTL for events

yaml dataset: events lifecycle:
- hot: 7d  # NVMe
- warm: 90d # SSD + zstd
- cold: 365d # object store
- delete

13. 4 Carbon-aware ETL

python co2 = kwh_estimate(job) grid_factor(region, now())
if co2 > job.threshold and job.deferable:
delay(job, until=next_green_window())
else:
run(job)

14) Architect checklist

1. Energy (J/req, kWh/job) and carbon (gCO₂e/req) SLIs determined?
2. Is there a model for attributing energy by services/features/tenants?
3. Carbon-aware scheduler for portable tasks implemented?
4. Microservices minimize chatting (aggregation, batches, gRPC/HTTP3)?
5. Are caches with coalescing and stale-while-revalidate configured?
6. Are the stores toned, ILM/TTL enabled, data formats optimal?
7. ML: distillation/quantization/butching/inference compilation are used?
8. CI/CD has energy-smoke, baselines and gates on the J/req Δ?
9. Edge/CDN/regional placement minimize egress and routes?
10. DVFS/power-capping/idle for workers enabled?
11. Are logs/metrics/trails sampled and retented in importance?
12. Green runbook documented: what to turn off/degrade when energy is scarce?

Conclusion

Energy efficient architecture is not the "last optimization," but a strategic layer of quality: from algorithms and formats to placement in the "green" region and gates in CI/CD. Measure joules, plan with carbon in mind, simplify interactions, thaw data and use accelerators where it reduces "J/op." So you get a platform that is faster, cheaper and greener - without compromising on product value.