Zhuque-3: como devs implementam retry e circuit breaker

Quando vi a notícia do pouso do Zhuque-3, a primeira coisa que me veio à cabeça não foi espaço — foi um loop de retry com backoff exponencial que implementei semana passada. Sério. A engenharia por trás de recuperar um booster orbital tem mais em comum com o nosso dia a dia de código do que parece à primeira vista. Vou explicar por quê.

O que realmente aconteceu na China (e por que devs deveriam prestar atenção)

Segundo o Olhardigital.com.br, a chinesa LandSpace recuperou pela primeira vez o primeiro estágio de um foguete após um voo orbital, pousando verticalmente em Minqin, na província de Gansu. O veículo caiu a apenas 2,4 metros do ponto previsto, a 0,75 m/s. Para um booster que gira a Mach 7 minutos antes, isso é absurdo.

Mas o detalhe que me chamou atenção foi outro: a empresa já fazia testes desde janeiro de 2024, com altitudes crescentes (350 m, depois 10 km), refinando o sistema antes de tentar a manobra completa. Isso é literalmente TDD aplicado a foguetes. Versão pequena, valida, escala, valida de novo, vai pra produção.

A matemática do pouso (que não é tão diferente da sua)

Quando você controla um foguete voltando do espaço, está resolvendo em tempo real um sistema dinâmico com variáveis que mudam a cada毫segundo. Os engenheiros usam combinações de:

• Controladores PID — os mesmos que aparecem em firmware de impressoras 3D, drones e termostatos inteligentes. A ideia é simples: proporcional + integral + derivativo. Mas ajustá-los para um booster de dezenas de toneladas é outro jogo.
• Filtros de Kalman — fusão de dados de GPS, IMU, radar e telemetria para estimar posição real apesar de sensores ruidosos. É literalmente o que você implementa em trackers de objetos quando o vídeo tem glitch.
• State machines finitas — o foguete tem estados discretos (boost, coast, reentry burn, landing burn, touchdown) com transições validadas. Mesma arquitetura de um workflow engine que você talvez já tenha construído.

Na minha experiência, qualquer dev que já implementou uma máquina de estado decente consegue ler o código de bordo de um foguete e se reconhecer. A diferença é que o nosso “deploy” pode falhar de forma inconvenientemente explosiva.

Por que foguetes reutilizáveis são o “serverless” do setor espacial

Essa é a parte que mais me interessa como profissional de tech. A analogia é direta:

A SpaceX provou que reusar o hardware derruba o custo marginal por lançamento. A China agora também entrou nesse clube com o Zhuque-3. Quando você internaliza isso, entende que o “cloud” da exploração espacial está nascendo — e o software é o que permite escalar.

Na Prática: implementando o “pouso controlado” em microserviços

Para deixar isso tangível, vou mostrar um padrão que uso em produção e que tem a mesma filosofia de “graceful degradation” de um foguete voltando para casa. É o padrão de retry com circuit breaker e fallback controlado — o equivalente a “se a queima de reentrada falhar, ligue a queima de pouso”.

import CircuitBreaker from 'opossum';

interface RetryOptions {
  maxAttempts: number;
  baseDelayMs: number;
  maxDelayMs: number;
  jitter: boolean;
}

const defaultOptions: RetryOptions = {
  maxAttempts: 5,
  baseDelayMs: 100,
  maxDelayMs: 5000,
  jitter: true,
};

async function sleep(ms: number): Promise<void> {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

export async function controlledRetry<T>(
  fn: () => Promise<T>,
  opts: Partial<RetryOptions> = {},
): Promise<T> {
  const options = { ...defaultOptions, ...opts };
  let lastError: unknown;

  for (let attempt = 1; attempt <= options.maxAttempts; attempt++) {
    try {
      // Tentativa primária — equivalente à queima orbital
      return await fn();
    } catch (err) {
      lastError = err;
      console.warn(`[retry] attempt ${attempt}/${options.maxAttempts} failed`);

      if (attempt === options.maxAttempts) break;

      // Backoff exponencial com jitter — assim como o foguete
      // desacelera progressivamente na reentrada
      const expDelay = Math.min(
        options.baseDelayMs * 2 ** (attempt - 1),
        options.maxDelayMs,
      );
      const delay = options.jitter
        ? Math.random() * expDelay
        : expDelay;

      await sleep(delay);
    }
  }

  throw lastError;
}

// Circuit breaker — o "abort" do foguete se algo der muito errado
const breaker = new CircuitBreaker(
  async (payload: unknown) => callPrimaryService(payload),
  {
    timeout: 3000,
    errorThresholdPercentage: 50,
    resetTimeout: 30000,
  },
);

// Fallback controlado — última chance antes do "pouso de emergência"
breaker.fallback(() => callSecondaryService());

export async function executeWithSafety<T>(payload: T): Promise<unknown> {
  return controlledRetry(() => breaker.fire(payload), {
    maxAttempts: 4,
    baseDelayMs: 200,
    maxDelayMs: 4000,
  });
}

Esse padrão tem três camadas — tentativa, repetição inteligente e circuito de segurança — exatamente como o Zhuque-3 tem queima principal, retrofoguetes e paraquedas de emergência. Não é coincidência. Sistemas distribuídos resilientes e sistemas aeroespaciais compartilham a mesma restrição fundamental: quando algo dá errado em produção, não dá para pedir “Ctrl+Z”.

Comparando os players: quem está fazendo o quê em reuso orbital

Vale contextualizar o feito da LandSpace porque o cenário está mais competitivo do que a manchete sugere:

• SpaceX (EUA) — Falcon 9 já reusou o mesmo booster mais de 20 vezes. Recupera em drones-barco ou em terra. É o padrão da indústria.
• Blue Origin (EUA) — New Shepard recupera propulsores suborbitais desde 2015. Orbital ainda em desenvolvimento no New Glenn.
• LandSpace (China) — Zhuque-3 fez o primeiro reuso orbital chinês em terra. Combustível é metano líquido (methalox), mesma escolha do Starship.
• Galactic Energy, iSpace (China) — outras empresas privadas chinesas também trabalham em recovery, ainda em estágios de teste.

O ponto é: a China não está atrás — está entrando em um mercado aquecido, com aprendizados de quem veio antes. Se você trabalha com infra ou cloud, sabe que seguir o pioneiro às vezes é vantagem competitiva. Você copia o que funciona e itera.

Erros comuns que devs cometem ao tentar “recuperar” sistemas em produção

Falando em copiar o que funciona, aqui vão armadilhas que vejo em código real e que também explicam por que tantos testes de pouso fracassam:

1. Não instrumentar antes de tentar recuperar. A LandSpace voou três vezes antes do sucesso com altitudes crescentes. Em software, vejo gente deployando circuit breaker sem métricas de taxa de erro. Você está operando no escuro.
2. Backoff sem jitter. Se todos os workers retentam ao mesmo tempo, você causa uma thundering herd. O foguete não tem esse problema (só existe um), mas em microsserviços isso derruba sistemas inteiros.
3. Esquecer o caso de “missão impossível”. Toda máquina de estado precisa de um estado terminal documentado. No foguete, é a detonação controlada. No seu sistema, é uma resposta 503 explícita, não um timeout infinito.
4. Refurbishment preguiçoso. Reusar um booster sem inspeção adequada mata gente. Reusar uma conexão de pool sem health check causa memory leaks e travamentos. A manutenção entre usos importa mais do que o reuso em si.
5. Confundir “recuperou uma vez” com “é confiável”. Um pouso bem-sucedido é prova de conceito, não SLA. Mesma lógica de “funcionou na minha máquina” versão hardware.

Implicações práticas para quem programa

Ok, mas o que isso muda no seu dia a dia? Mais do que você imagina, em três frentes:

• Demanda por engenheiros de software aeroespacial vai explodir. A SpaceX, Rocket Lab, Relativity e agora LandSpace estão contratando devs generalistas que entendem sistemas distribuídos. Se você já mexe com Rust, Go ou TypeScript, está mais perto do que pensa.
• Padrões de resiliência vão virar commodities. Hoje você implementa retry+breaker à mão. Em poucos anos, frameworks de simulação orbital vão emprestar (e devolver) técnicas para o nosso dia a dia. Fique antenado.
• Custos de lançamento mais baratos significam mais dados em órbita. Menos dinheiro por kg = mais constelações de satélites, mais imagens, mais dados ambientais. Se você trabalha com data engineering, é um convite para novos pipelines.

FAQ — o que devs realmente perguntam sobre isso

1. Foguete reutilizável é realmente mais barato ou é marketing?

É mais barato, comprovadamente. A SpaceX divulga reduções de custo de 30–50% por lançamento com booster reusado. A conta é simples: o propelente de um Falcon 9 custa cerca de US$ 200 mil. O foguete novo custa US$ 50 milhões. Reusar o hardware muda a equação completamente.

2. Por que pousar em terra e não em barco?

Pousar em terra geralmente permite mais margem de erro e recuperação mais rápida, sem o movimento do mar. A SpaceX pousa em terra em boosters que voltam de missões com menor demanda de performance. Barco (drone ship) é usado quando o booster tem pouca reserva de combustível depois da missão — ele pousa onde a órbita o deixou, não onde a SpaceX queria.

3. Qual a relação entre metano e oxigênio líquido (methalox) que o Zhuque-3 usa?

Methalox é mais barato que querosene (RP-1), queima mais limpo (menos fouling nos motores, então refurbishment é mais rápido) e permite missões a Marte (metano pode ser produzido in-situ em Marte via reação de Sabatier). Por isso SpaceX, Blue Origin, LandSpace e outros apostam nele.

4. Posso trabalhar com software espacial sem ser aeroespacial de formação?

Sim. A maioria das vagas modernas pede proficiência em C++, Rust, Python, sistemas embarcados, visão computacional e sistemas distribuídos. Conhecimento de controle e dinâmica fica na equipe de GNC (Guidance, Navigation and Control). Sua experiência com microserviços e tempo real é valiosa.

5. O feito da China muda alguma coisa geopolítica?

Programaticamente, significa que o “monopólio” do reuso orbital não é mais exclusivo de empresas dos EUA. Mais players = mais inovação = mais pressão sobre preços. Para nós, devs, isso se traduz em mais ferramentas, APIs e dados disponíveis.

Considerações finais

O que mais me fascina no feito da LandSpace é a mentalidade iterativa. Eles não tentaram pousar o booster direto — fizeram três testes em altitudes crescentes, aprenderam, ajustaram, e só então executaram a manobra completa. É a mesma filosofia que aplico em CI/CD: você não deploya para 100% dos usuários depois de uma única execução em staging.

Se você trabalha com tecnologia, vale parar alguns minutos para pensar em como seus sistemas “pousam” depois de uma falha. Eles descontroladamente explodem, ou têm caminhos graceful de recuperação? É uma pergunta que, depois de ver o Zhuque-3 acertar o alvo a 2,4 metros de precisão, fica impossível de ignorar.

⭐ Curtiu? Me segue no GitHub

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.