4.9 Enable Asynchronous Processing and Communication

Depending on carbon intensity, some processes and communications should be delayed and sometimes batched. This could also be a way to reduce the workload on a server or Virtual Machine (VM). In such cases, visitors should be warned that the process is asynchronous and notified when it is over.

Criteria

Batch Processing: By default, non-critical processes and communications are batched and launched only when carbon intensity is under a given threshold.
Protocol Usage: The communication protocols used are relevant to the visitor’s needs and data transferred. Avoid using insecure protocols (HTTP, FTP), and prioritize more efficient and privacy-aware data routes for visitors (HTTPS, SSH).
Event-Driven Architecture: When creating products or services that utilize state changes (without triggering a complete refresh), if the utilization of Event-Driven Architecture and Microservices will be more environmentally friendly (based on the PPP variables involved) than traditional APIs in handling the server-side workload of your solution, use it.

Impact

Medium

Effort

Medium

Benefits

Environmental:
The potential reduction in a workload by running processes in batches could help reduce the intensity of peak hardware thrashing, thereby reducing the energy requirements and potentially even the water requirements for cooling (due to excess heat generation).
Social Equity:
Leaving non-critical processes to run during quieter periods may reduce the opportunity for sites or services to experience downtime or slowdown due to being overburdened.

GRI

materials: Low
energy: Low
water: Low
emissions: Low

Example

When the visitor asks for the generation of a downloadable file, the visitor is informed that the request will be handled asynchronously and given an estimation of the maximum time it will take. When the file is available, the visitor receives a communication in the most sustainable manner, such as an SMS. As such, it is better if the file is made available online and then deleted after a given amount of time. Ideally, the visitor should be given the option to cancel the request.

Resources

View the Guideline