“Elegir una región más limpia” no constituye por sí solo una estrategia de arquitectura. Primero reduce la energía necesaria para entregar trabajo útil; después decide qué cargas pueden esperar o trasladarse, respetando latencia, residencia de datos, disponibilidad y recuperación.
En las conversaciones sobre energía es fácil pasar de una cifra general de los centros de datos a una afirmación sobre una API concreta sin explicar la relación entre ambas. Esa relación es la medición. Una comparación útil define los límites del sistema, el trabajo entregado, los recursos aprovisionados y las hipótesis de la estimación energética o de emisiones. Sin eso, menos servidores quizá solo signifique que el trabajo se trasladó o que el usuario espera más.
En su análisis de 2026, la Agencia Internacional de la Energía describió un aumento acelerado de la demanda eléctrica de los centros de datos, especialmente de las instalaciones centradas en IA. Por eso, la eficiencia y la programación de cargas son cuestiones prácticas de arquitectura. No implica perseguir la intensidad de carbono a costa de la fiabilidad o de los requisitos legales de ubicación de los datos.
La especificación Software Carbon Intensity (SCI) de Green Software Foundation expresa las emisiones como una tasa por unidad funcional. De forma simplificada, combina la energía operativa con la intensidad de carbono de la electricidad en la ubicación y una parte asignada del impacto del hardware, y lo divide por la unidad de trabajo elegida.
E es la energía dentro de los límites definidos del software; I, la intensidad de carbono pertinente de la red eléctrica; M, la parte asignada del impacto incorporado del hardware; y R, la unidad funcional, por ejemplo una solicitud API exitosa, una transacción, una imagen procesada o un lote terminado. La especificación formal detalla las reglas de medición y asignación; esta ecuación es una simplificación explicativa.
Elige una unidad que represente el valor entregado, no solo actividad de infraestructura. “kWh por millón de solicitudes completadas correctamente” es más útil que “bajó el uso de CPU” si también aumentaron los reintentos o la latencia. En una carga de IA, mide energía o emisiones estimadas por tarea junto con calidad, tokens, caché y fallos. Indica si las cifras son medidas o modeladas.
Son valores didácticos, no resultados de benchmarking. Para un gráfico real, utiliza ejecuciones repetibles con la misma carga, datos, criterios de éxito, SLO y límites de medición.
El software puede consumir menos energía para realizar la misma función si evita trabajo innecesario: cachear lecturas estables, deduplicar eventos, procesar por lotes, reducir serialización y transferencia de datos, elegir modelos adecuados a la tarea, limitar el polling y ajustar la capacidad aprovisionada. Mide el recorrido completo: aplicación, base de datos, red, almacenamiento, reintentos y servicios gestionados incluidos en el alcance.
Las solicitudes interactivas tienen objetivos de latencia y disponibilidad visibles para los usuarios. Trasladarlas para aprovechar una señal eléctrica horaria puede aumentar la distancia, reducir redundancia o infringir reglas de residencia. Mejores candidatas son las tareas en cola que toleran demoras: analítica no urgente, evaluación de modelos, generación de informes, compactación, copias de seguridad compatibles con los objetivos de recuperación y algunos entrenamientos.
Expresa la flexibilidad en el contrato de la tarea: inicio más temprano, fecha límite, demora máxima, regiones permitidas, clasificación de datos, duración estimada, política de reintentos y posibilidad de recalcular el resultado. El scheduler solo debe optimizar dentro de esos límites. Si la señal está desactualizada o la región preferida no está disponible, vuelve al objetivo normal del servicio en vez de esperar indefinidamente.
| Carga | Estrategia probable | Salvaguarda |
|---|---|---|
| API interactiva | Optimiza código, caché, base de datos y modelo; elige una región cercana y autorizada. | El SLO de latencia, residencia y disponibilidad prevalece sobre la optimización horaria. |
| Informe diario | Encola dentro de una ventana y programa según energía o capacidad. | Plazo estricto, frescura de las entradas y reejecución idempotente. |
| Evaluación de modelos | Agrupa casos de prueba, programa suites flexibles y usa modelos pequeños para el filtrado inicial. | Validez, reproducibilidad y calendario del gate de publicación. |
| Backup / compactación | Limita velocidad, escalona tareas y evita picos concurrentes cuando sea posible. | RPO, retención y velocidad de restauración. |
Las recomendaciones de los proveedores cloud plantean considerar el carbono junto con requisitos de negocio, rendimiento y coste. Una red eléctrica de menor intensidad no convierte automáticamente esa región en la opción correcta. Comprueba residencia y soberanía de datos, latencia, disponibilidad de servicios, recuperación ante desastres, transferencia de salida, capacidad y precios. Compara escenarios equivalentes y documenta la decisión.
Para lotes, trasladar la hora de ejecución dentro de una región aprobada puede ser más sencillo que cruzar fronteras con los datos. En servicios sensibles a la latencia, la proximidad y la redundancia pueden ser decisivas. Los datos de intensidad también varían en resolución y metodología: un promedio regional anual no equivale a una señal marginal horaria. Registra origen, fecha, región y si el factor es promedio o marginal.
Define una demora limitada, edad máxima de cola, fallback explícito y circuit breaker para señales defectuosas. Evita liberar todas las tareas aplazadas en la misma hora “verde”: usa jitter y límites de tasa según la capacidad. Observa el trabajo completado a tiempo, energía por unidad, emisiones estimadas por unidad, latencia, fallos y coste.
Empezaría con una carga no urgente y un benchmark repetible. Añadiría al contrato de la tarea un plazo, conjunto de regiones permitidas, clasificación de datos, clave de idempotencia y ventana flexible. Instrumentaría cola y uso de recursos; calcularía una referencia de energía por salida con el mismo método en cada comparación. Después incorporaría un servicio de políticas que recibe datos de intensidad eléctrica con marca de tiempo, pero solo puede elegir entre ubicaciones y horarios aprobados.
En sistemas cloud-native, publicaría métricas por carga y anotaría cada despliegue con los límites y la versión del estimador. El panel debería comparar tasas tipo SCI y objetivos del servicio, no mostrar una única puntuación “verde”. Un cambio solo aporta valor si reduce el impacto por trabajo equivalente sin degradar la calidad ni desplazar el coste a otro componente.
| Fallo | Señal | Control |
|---|---|---|
| Se completa menos trabajo | Baja la energía por hora, pero suben los fallos, la cola o los retrasos. | Normaliza por unidades completadas y conserva el objetivo de calidad/SLO. |
| Señal de carbono antigua o incorrecta | El scheduler usa datos desactualizados o de otra red eléctrica. | Valida fecha, región y antigüedad máxima; registra el fallback. |
| Las tareas aplazadas se liberan juntas | La cola y el throttling se disparan en el mismo intervalo. | Usa jitter, límite de concurrencia y despacho atento a la edad de cola. |
| El traslado rompe residencia o recuperación | Los datos cruzan un límite o empeora la cobertura de restauración. | Aplica la política antes de optimizar y prueba replicación y recuperación. |
| La estimación se presenta como medición | Las cifras modeladas aparecen con precisión injustificada. | Indica método, hipótesis, límites, incertidumbre y fuente del factor. |
La arquitectura consciente de la energía es una disciplina de medición y programación, no una clasificación de regiones. Define el trabajo útil, reduce los recursos necesarios y solo después traslada las cargas flexibles respetando plazos y límites explícitos de residencia, latencia y recuperación. Publica el alcance y el método, vincula el impacto con la calidad y usa el SLO habitual como fallback cuando falten señales fiables.
Nota editorial: Este artículo describe métodos de ingeniería; no afirma que una carga o región concreta tenga una huella específica. Consulta la metodología SCI y las recomendaciones del proveedor para cálculos formales y datos actuales de cada servicio.