“Escolher uma região mais limpa” não é, por si só, uma estratégia de arquitetura. Primeiro reduza a energia necessária para entregar trabalho útil; depois decida o que pode esperar ou mudar de lugar, respeitando latência, residência dos dados, disponibilidade e recuperação.
Em discussões sobre energia, é comum sair de um dado amplo sobre data centers e chegar a uma afirmação sobre uma API específica sem mostrar a ligação entre as duas coisas. Essa ligação é a medição. Uma comparação útil define os limites do sistema, o trabalho entregue, os recursos provisionados e as premissas da estimativa de energia ou emissões. Sem isso, menos servidores podem apenas significar que o trabalho migrou ou ficou mais lento para o usuário.
A Agência Internacional de Energia descreveu, em sua análise de 2026, o aumento acelerado da demanda elétrica de data centers, especialmente instalações voltadas a IA. Eficiência e agendamento, portanto, são preocupações concretas de arquitetura. Isso não significa perseguir intensidade de carbono à custa da confiabilidade ou das exigências legais de localização dos dados.
A especificação Software Carbon Intensity (SCI), da Green Software Foundation, expressa emissões como uma taxa por unidade funcional. Em forma simplificada, combina a energia operacional com a intensidade de carbono da eletricidade no local e uma parcela alocada do impacto de hardware, dividindo o resultado pela unidade de trabalho escolhida.
E representa a energia dentro dos limites definidos para o software; I é a intensidade de carbono relevante da rede elétrica; M é a parcela alocada do impacto incorporado no hardware; e R é a unidade funcional, por exemplo, uma requisição de API concluída, uma transação, uma imagem processada ou um lote finalizado. A especificação formal detalha medição e alocação; a fórmula acima é apenas uma simplificação didática.
Escolha uma unidade que represente valor entregue, não apenas atividade de infraestrutura. “kWh por milhão de requisições bem-sucedidas” ajuda mais que “a utilização da CPU caiu” se também aumentaram as tentativas repetidas ou a latência. Em IA, acompanhe energia ou emissões estimadas por tarefa concluída junto com qualidade, tokens, cache e falhas. Informe se os números foram medidos ou modelados.
São valores didáticos, não resultados de benchmark. Para um gráfico real, use execuções repetíveis com a mesma carga, os mesmos dados, critérios de sucesso, SLO e limites de medição.
É possível gastar menos energia para entregar a mesma função evitando trabalho desnecessário: cache de leituras estáveis, deduplicação de eventos, processamento em lotes, menos serialização e transferência, modelos adequados à tarefa, menos polling e capacidade dimensionada corretamente. Meça o caminho completo: aplicação, banco, rede, armazenamento, tentativas repetidas e serviços gerenciados que estejam dentro do escopo.
Requisições interativas têm metas de latência e disponibilidade percebidas por usuários. Deslocá-las para aproveitar um sinal horário da rede pode aumentar a distância, reduzir a redundância ou violar regras de residência. Candidatos melhores são jobs em fila que toleram atraso: analytics não urgentes, avaliação de modelos, geração de relatórios, compactação, backups compatíveis com os objetivos de recuperação e alguns treinamentos.
Expresse a flexibilidade no contrato do job: início mais cedo, prazo final, atraso máximo, regiões permitidas, classe dos dados, estimativa de duração, política de retry e possibilidade de recomputar. O scheduler só pode otimizar dentro desses limites. Se o sinal estiver desatualizado ou a região preferida estiver indisponível, volte ao objetivo do serviço em vez de esperar indefinidamente.
| Carga | Estratégia provável | Proteção |
|---|---|---|
| API interativa | Otimize código, cache, banco e modelo; escolha região próxima e autorizada para os dados. | SLO de latência, residência e disponibilidade prevalecem sobre otimização horária. |
| Relatório diário | Enfileire dentro de uma janela e agende conforme energia ou capacidade. | Prazo rígido, atualidade das entradas e reexecução idempotente. |
| Avaliação de modelos | Agrupe casos de teste, programe suítes flexíveis e use modelos menores na triagem. | Validade, reprodutibilidade e horário do gate de release. |
| Backup / compactação | Limite taxa, distribua horários e evite picos concorrentes quando possível. | RPO, retenção e velocidade de restauração. |
As orientações dos provedores cloud recomendam considerar carbono junto com requisitos de negócio, desempenho e custo. Uma rede elétrica com menor intensidade não torna automaticamente aquela região adequada. Verifique residência e soberania dos dados, latência para usuários, disponibilidade de serviços, recuperação de desastre, tráfego de saída, capacidade e preço. Compare cenários equivalentes e documente a escolha.
Em jobs de lote, deslocar o horário dentro de uma região aprovada pode ser mais simples do que transferir dados entre fronteiras. Em serviços sensíveis à latência, proximidade e redundância podem ser decisivas. Os dados de intensidade também variam em resolução e método: média anual regional não é o mesmo que sinal marginal horário. Registre origem, horário, região e se o fator representa média ou margem.
Defina atraso máximo, idade máxima da fila, fallback explícito e circuit breaker para sinais ruins. Evite liberar todos os jobs adiados no mesmo instante “verde”: use jitter e limites de taxa considerando a capacidade. Acompanhe trabalho bem-sucedido no prazo, energia por unidade, emissões estimadas por unidade, latência, falhas e custo.
Começaria com uma carga não urgente e um benchmark repetível. Adicionaria ao contrato do job prazo, regiões permitidas, classificação dos dados, chave de idempotência e janela de flexibilidade. Instrumentaria fila e consumo de recursos; calcularia uma referência de energia por saída com o mesmo método em cada comparação. Depois incluiria um serviço de política que recebe dados de intensidade da rede com timestamp, mas só escolhe entre locais e horários aprovados.
Em sistemas cloud-native, publicaria métricas por workload e registraria nos deploys os limites e a versão do estimador. O painel deveria comparar taxas do tipo SCI e objetivos do serviço em conjunto, não exibir uma nota “verde” isolada. Uma mudança só ajuda se reduzir impacto por trabalho equivalente sem piorar qualidade ou deslocar custos para outro lugar.
| Falha | Sinal | Controle |
|---|---|---|
| Menos trabalho concluído | Energia por hora cai, mas aumentam falhas, fila ou atrasos. | Normalize por unidades concluídas e preserve a meta de qualidade/SLO. |
| Sinal de carbono velho ou incompatível | O scheduler usa dado antigo ou da rede errada. | Valide timestamp, região e idade máxima; registre o fallback. |
| Liberação em massa de jobs | Fila e throttling disparam no mesmo horário. | Use jitter, limite de concorrência e despacho atento à idade da fila. |
| Mudança viola residência ou recuperação | Dados cruzam uma fronteira ou a cobertura de restore piora. | Aplique política antes da otimização e teste replicação e restauração. |
| Estimativa é tratada como medição | Números modelados são publicados com precisão injustificada. | Identifique método, premissas, limites, incerteza e fonte do fator. |
Arquitetura consciente de energia é uma disciplina de medição e agendamento, não um ranking de regiões. Defina o trabalho útil, reduza os recursos necessários e só então mova cargas flexíveis dentro de prazos e restrições explícitos de residência, latência e recuperação. Publique os limites e o método, associe impacto à qualidade e use o SLO normal como fallback quando o sinal ambiental estiver ausente ou não for confiável.
Nota editorial: Este artigo descreve métodos de engenharia, não afirma que determinada carga ou região tenha uma pegada específica. Consulte a metodologia SCI e as orientações do provedor para cálculos formais e dados atuais de cada serviço.