Quando li a notícia de que a NASA esticou a vida útil da Voyager 2 reorganizando o consumo elétrico da sonda, a primeira coisa que me veio à cabeça foi: isso é exatamente o que a gente faz com sistemas legados em produção. Segundo o Olhardigital.com.br, engenheiros do JPL aplicaram uma estratégia chamada internamente de “Big Bang” para preservar três instrumentos científicos ativos por pelo menos mais um ano — substituindo equipamentos de alto consumo por alternativas mais econômicas, sem comprometer a operação. Em software, chamamos isso de refatoração orientada à restrição. E tem lições valiosas pra qualquer dev que mantém código em produção há anos.
Por que a Voyager 2 é o melhor case de legacy system que existe
A Voyager 2 foi lançada em 1977. O software de bordo foi escrito em Fortran, assembly e em uma linguagem proprietária da NASA que ninguém mais usa. Os processadores têm capacidade menor que a de um micro-ondas moderno. E, mesmo assim, ela continua transmitindo dados do espaço interestelar — a mais de 20 bilhões de quilômetros da Terra.
Na minha experiência mantendo sistemas legados, o paralelo é direto: quando o ambiente operacional muda (energia disponível, latência de rede, custo de cloud), você não reescreve do zero. Você reorganiza o consumo. A NASA desligou dois instrumentos por sonda desde 2024 justamente por causa da perda anual de ~4 watts por gerador — energia que vem da decomposição do plutônio-238 em geradores termoelétricos de radioisótopos (RTGs).
Esse número é brutal se você traduzir para software: imagine perder 4% da sua cota de CPU por ano, sem possibilidade de upgrade de hardware. Você precisa decidir, todo ano, o que manter vivo e o que desligar. É literalmente o mesmo problema que devs enfrentam com licenças que expiram, infra legada que ninguém quer migrar ou microserviços antigos consumindo orçamento de cluster.
A estratégia “Big Bang” e o que devs podem aprender
1. Identifique os consumidores desproporcionais
O primeiro passo da NASA foi mapear o que gastava mais energia. Em código, a gente faz a mesma coisa com profilers: New Relic, Datadog, py-spy, clinic.js, perf no Linux. Antes de otimizar, você precisa saber onde está o vazamento. Se você está “economizando energia” sem dados, está chutando.
2. Substitua por equivalentes de menor consumo
A Voyager trocou aquecedores e sistemas não essenciais por alternativas mais eficientes. Em software, isso se traduz em:
- Trocar
requestsporhttpxcom connection pooling - Substituir polling por webhooks ou server-sent events
- Migrar de JSON parsing com
jsonpadrão paraorjsonoumsgspec - Trocar ORM pesado por queries SQL bem escritas quando o overhead pesa
3. Desligue o que não é essencial
A NASA desligou instrumentos que eram úteis só para a fase de encontro com planetas. Em software, isso é o YAGNI operacional: se você tem um worker rodando a cada 5 minutos para uma feature que ninguém usa há 6 meses, mate-o. Se você tem um log verboso consumindo I/O em produção sem ninguém lendo, desabilite.
4. Garanta a saúde térmica do sistema
A equipe precisou verificar a temperatura da nave após as mudanças. Em hardware isso é óbvio, mas em software existe um equivalente: verificar o comportamento sob a nova configuração antes de promover. Carga sintética, canary deploys, shadow traffic. Você não desliga um instrumento da Voyager sem antes simular o impacto — e dev não deveria desativar um serviço em produção sem o mesmo cuidado.
Na Prática: simulando o dilema da Voyager em Python
Para visualizar o problema, escrevi um script curto que modela o orçamento de energia decrescente da sonda e mostra como decisões de design preservam a operação por mais tempo. É o tipo de raciocínio que aplico quando preciso justificar tecnicamente por que desligar uma feature em produção.
"""
Simulação do orçamento de energia decrescente da Voyager 2.
Cada ano perdemos ~4W. Instrumentos têm consumo fixo.
Objetivo: maximizar anos de operação com ≥ 1 instrumento ativo.
"""
INSTRUMENTOS = {
"magnetometro": {"watts": 8, "essencial": False, "fase_planetaria": True},
"plasma_ciencia":{"watts": 10, "essencial": False, "fase_planetaria": True},
"particulas": {"watts": 7, "essencial": True, "fase_planetaria": False},
"ondas_plasmas": {"watts": 9, "essencial": True, "fase_planetaria": False},
"espectrometro": {"watts": 11, "essencial": True, "fase_planetaria": False},
}
ORCAMENTO_INICIAL = 45 # watts disponíveis em 1977
PERDA_ANUAL = 4
FASE_INTERESTELAR_INICIO = 2012 # fim dos encontros planetários
def simular(anos=60, big_bang=False):
orcamento = ORCAMENTO_INICIAL
ativos = set(INSTRUMENTOS.keys())
historico = []
for ano in range(1977, 1977 + anos):
# aplica estratégia "Big Bang": desliga instrumentos não essenciais
if big_bang and ano == 2025:
for nome, inst in INSTRUMENTOS.items():
if not inst["essencial"]:
ativos.discard(nome)
historico.append((ano, "Big Bang aplicado", orcamento))
# calcula consumo total dos instrumentos ativos
consumo = sum(INSTRUMENTOS[i]["watts"] for i in ativos)
if consumo > orcamento:
# remove o menos essencial (mas ainda ativo) até caber
candidatos = sorted(
ativos,
key=lambda i: (INSTRUMENTOS[i]["essencial"], -INSTRUMENTOS[i]["watts"])
)
while consumo > orcamento and candidatos:
removido = candidatos.pop(0)
ativos.discard(removido)
consumo -= INSTRUMENTOS[removido]["watts"]
historico.append((ano, len(ativos), orcamento))
orcamento -= PERDA_ANUAL
if not ativos:
historico.append((ano, "MORTE", orcamento))
return historico
return historico
def comparar():
sem_bb = simular(big_bang=False)
com_bb = simular(big_bang=True)
ano_morte_sem = next((h[0] for h in sem_bb if h[1] == "MORTE"), "ainda viva")
ano_morte_com = next((h[0] for h in com_bb if h[1] == "MORTE"), "ainda viva")
print(f"Sem Big Bang : instrumento restante até ~{ano_morte_sem}")
print(f"Com Big Bang : instrumentos preservados até ~{ano_morte_com}")
if __name__ == "__main__":
comparar()
Rodando essa simulação, fica óbvio o ganho da estratégia: trocar várias otimizações marginais por um corte cirúrgico de uma única vez preserva operação por anos a mais. É a mesma lógica de uma grande migração técnica versus dezenas de patches pequenos que só empurram o problema pra frente.
Erros comuns que devs cometem (e a NASA não)
1. Otimizar sem medir
Já vi gente desligar cache “porque estava consumindo memória”. Resultado: latência triplicou e ninguém entendeu por quê. A NASA mapeou watt por watt antes de mover qualquer chave. Você deveria fazer o mesmo: prom-client, OpenTelemetry, logs estruturados, traces distribuídos. Sem dado, é achismo.
2. Achar que reescrever é mais barato que otimizar
Tem uma cultura ruim em software de que reescrita total é a solução. A NASA não tem esse luxo — o código da Voyager roda em hardware que não existe mais. A solução é otimizar dentro da restrição. Se você está olhando para um monólito com 500k linhas, antes de propor reescrita, proponha uma estratégia estilo “Big Bang”: corte de funcionalidades de baixo valor, troca de componentes críticos, instrumentação. Geralmente é mais barato e mais seguro.
3. Ignorar restrições físicas do ambiente
A Voyager precisa manter componentes aquecidos porque o espaço interestelar é frio demais. Tradução pra software: você tem ambiente de produção com latência de rede alta, disco lento, memória limitada (bare metal, edge, IoT, Lambda com pouca RAM). Não trate como se fosse seu MacBook M3. Profile no ambiente real, sempre.
4. Não documentar o porquê das decisões
Se a NASA desligasse um instrumento e não registrasse o motivo, a próxima equipe perderia horas tentando entender. Em código, comentários explicando o “porquê” valem mais que comentários explicando o “como”. O “como” o código já mostra.
5. Subestimar o custo de manter sistemas antigos
A Voyager 2 custa caro de manter — antena de 70 metros, equipe dedicada, simulações complexas. Sistemas legados também custam. Mas o cálculo precisa ser honesto: às vezes manter é mais barato que migrar. E às vezes é o contrário. A NASA faz essa conta todo ano; você deveria fazer também.
Comparativo: Voyager vs. sistemas em produção
| Aspecto | Voyager 2 | Sistema legado típico |
|---|---|---|
| Recurso crítico | Energia elétrica (decaimento de Pu-238) | Orçamento de cloud / licenças / equipe |
| Perda anual | ~4 watts/ano | Crescimento técnico (dependências, frameworks, dívida) |
| Estratégia | Desligar instrumentos não essenciais | Deprecation de features, consolidação de serviços |
| Risco de mudança | Irreversível (não tem como “rebuildar”) | Alto se feito sem feature flags e rollback |
| Documentação | Obrigatória e auditada | Frequentemente negligenciada |
Implicações para o seu trabalho como dev
Se você trabalha com qualquer sistema que precisa rodar por anos sem substituição — sistemas bancários, ERPs, infra crítica de telecom, dispositivos embarcados, satélites —, os princípios da Voyager se aplicam diretamente:
- Energia é recurso finito. Trate CPU, RAM, banda e orçamento como finitos. Decida o que vale a pena manter.
- Refatoração sob restrição > reescrita completa. 95% das vezes.
- Cada desligamento precisa de justificativa documentada. Seu “eu do futuro” vai agradecer.
- Monitore o decaimento. Toda métrica cai com o tempo. Antecipe.
Quando você assume um sistema legado, a primeira pergunta não é “como reescrevo?”. É: “qual é o recurso que está mais escasso e o que eu desligo primeiro?”. Isso é engenharia, não administração.
FAQ
A Voyager 2 ainda está transmitindo dados hoje?
Sim. Em 2025, ela continua enviando dados do espaço interestelar, a mais de 20 bilhões de km da Terra. O sinal chega com potência de ~20 watts quando emitido e precisa de antenas enormes para ser captado — o que dá uma dimensão da engenharia envolvida.
Por que a NASA não lança uma sonda nova em vez de economizar energia na Voyager?
Já lançou — as Voyager foram sucedidas por missões como New Horizons, Cassini e as futuras Uranus Probe proposals. Mas cada sonda tem custo bilionário e anos de desenvolvimento. Manter a Voyager 2 viva é, na prática, um telescópio gratuito no espaço interestelar.
Quanto tempo a Voyager 2 ainda tem de vida útil?
Com a estratégia “Big Bang”, a expectativa é manter três instrumentos por pelo menos mais um ano. Modelos mais otimistas projetam operação até o final dos anos 2020, dependendo de falhas não previstas. Mas cada ano é bônus.
Que lição de engenharia de software a Voyager 2 ensina?
A principal é que sistemas bem desenhados são projetados para durar. Código modular, instrumentação, documentação obsessiva e disciplina para desligar o que não é essencial são o que separa um projeto que dura 5 anos de um que dura 50. A Voyager está indo completar 50.
Existe paralelo entre RTG (gerador da Voyager) e baterias em dispositivos modernos?
Direto. Dispositivos IoT, satélites LEO, sensores remotos — todos enfrentam o mesmo problema de orçamento de energia decrescente. O gerenciamento de energia em firmware embarcado aplica exatamente os mesmos princípios que a NASA aplicou na Voyager: duty cycle, sleep modes, desligamento seletivo de subsistemas.
A Voyager 2 é, no fundo, o melhor professor de engenharia de software que existe — e não cobra R$ 500/hora. Cada decisão que a NASA tomou nessa otimização é uma aula sobre como tratar recursos finitos em sistemas de longa duração. Se você leva a sério manter código em produção por mais de uma década, vale a pena estudar o caso a fundo.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.