Multi-region (em planejamento Q4 2026)

Status em 2026-04-26: multi-region nativo não está disponível. O recurso entrou no roadmap para o quarto trimestre de 2026. Esta página existe para te ajudar a se preparar — e mostrar como conviver bem sem ele até lá.

Por que multi-region importa

Três motivos principais:

1. Latência regional. Servir um usuário no Recife a partir de Virginia adiciona 130ms ida-e-volta antes mesmo da aplicação responder. Para alguns produtos, é tolerável. Para outros, é a diferença entre vender e perder venda.
2. Disaster recovery. Um datacenter inteiro pode cair. Provedor inteiro pode ficar fora por horas. Estar presente em outra região te dá um plano B real.
3. Compliance e residência de dados. A LGPD favorece dados de cidadãos brasileiros em território nacional. GDPR é mais explícita ainda na Europa. Para vender em mercados regulados, a região onde o dado vive deixa de ser um detalhe técnico.

Como rodar em várias regiões hoje

Sem suporte nativo, o caminho atual envolve clusters independentes — um por região — coordenados por DNS.

Topologia típica:

                        Cloudflare DNS
                       (geo steering)
                              │
                ┌─────────────┼─────────────┐
                │             │             │
        cluster-br      cluster-us    cluster-eu
        (São Paulo)    (Virginia)    (Frankfurt)
        4 nós          4 nós         4 nós

Cada cluster:

• Roda independente. Tem o próprio plano de controle.
• Recebe os mesmos jobs, configurados separadamente.
• Tem o próprio backup, próprios secrets, próprias métricas.

O DNS resolve o usuário para o cluster mais próximo. Cloudflare Geo Steering ou AWS Route 53 com latency-based routing fazem esse trabalho.

Pontos a observar

• Mudanças precisam ser aplicadas em todos os clusters. Para isso vale a pena automatizar — mesmo que seja com um script que faz heroctl jobs submit em cada cluster.
• Secrets vivem isolados. Atualizar uma senha em um cluster não atualiza nos outros.
• Banco de dados é problema separado. Réplicas de leitura por região, escrita centralizada, ou modelos active-active — escolha sua estratégia. Não tem mágica aqui.

Cenários comuns

Startup brasileira que quer expandir

Topologia mínima: um cluster em São Paulo, um cluster em US-East. DNS roteia por proximidade.

Vantagem: usuário brasileiro tem latência baixa local; cliente internacional não sente o atraso de cruzar o Atlântico duas vezes.

Empresa com clientes em mercados regulados

Cluster BR para cliente brasileiro. Cluster EU para cliente europeu. Cluster US para o resto.

Cada cluster fica em jurisdição apropriada. Dados não atravessam fronteiras a menos que você decida explicitamente.

Disaster recovery puro

Não importa onde o usuário está — você só quer um plano B se o provedor primário cair.

Cluster ativo + cluster passivo em outra região. DNS aponta para o ativo. Em desastre, troca o DNS para o passivo. Restore o snapshot mais recente lá. Tempo de recuperação: minutos a uma hora, dependendo do tamanho.

Trade-offs honestos

Multi-region não é grátis. Os custos:

• Latência cross-region. Sincronizar qualquer coisa entre regiões adiciona dezenas a centenas de milissegundos.
• Tráfego inter-região é caro. A maioria das nuvens cobra por GB que sai da região. Multiplique por escala e o número assusta.
• Operação cresce. Dois clusters não são duas vezes um cluster — são três vezes (porque a coordenação entre eles é trabalho novo).
• Debug fica mais difícil. Um problema que aparece numa região e não na outra exige hipóteses extras.

A regra prática: só vá multi-region quando o custo de não estar for maior que o custo de estar. Latência ruim que está perdendo cliente. Compliance que está bloqueando contrato. Risco de DR que mantém o time acordado de noite. Se nada disso é verdade, fique em uma região e durma melhor.

Roadmap

O que vem por aí no HeroCtl:

Datas indicativas. Coisas mudam.

Como se preparar agora

Mesmo sem suporte nativo, algumas decisões facilitam a transição:

• Mantenha definições de jobs em arquivos versionados. Você vai querer aplicar os mesmos jobs em mais de um cluster.
• Centralize secrets em um cofre externo. Vault, AWS Secrets Manager, ou similar. Cada cluster busca de lá.
• Pense no banco de dados desde já. Migrar para um modelo regional depois é mais doloroso que começar planejado.
• Documente seu RPO e RTO. Quanto de dado pode perder. Quanto pode ficar fora. As respostas guiam todas as outras decisões.

Interesse antecipado

Se você quer participar do beta de federação no Q4 2026, escreva para roadmap@heroctl.com com:

• Quantas regiões você opera hoje
• Volume estimado de jobs
• Restrições regulatórias relevantes

Selecionamos um grupo pequeno de parceiros para o programa antecipado. Feedback nessa fase molda o produto final.

Próximos passos

• Backup e restore — base de qualquer estratégia DR.
• Ingress — DNS e roteamento para múltiplos endpoints.
• Troubleshooting — problemas operacionais comuns.